On 10/10/25 05:42, Jeremy Stanley wrote:
On 2025-10-09 17:47:35 -0700 (-0700), melanie witt wrote: [...]
whether or not Nova supports the key types depends only on the version of the Python 'cryptography' library installed as it does not deal with the key types directly. [...]
What's the actual intent behind this check? Is it simply an attempt to prevent uploading bogus/malformed keys? If so, as Clark pointed out, the check has been trivially bypassable for years (in OpenDev we've been treating it as a feature).
Or is there some additional functionality in Nova that depends on being able to parse keys rather than just treating them as an opaque blob?
I just had a look at the code and the intent appears to be a combination of what you and Takashi mentioned.
In the code [1], the comment says, "Test that the given public_key string is a proper ssh key. The returned object is unused since pyca/cryptography does not have a fingerprint method." So it's a basic validation check (indirectly by calling load_ssh_public_key()) and at the same time it generates a fingerprint to return as a REST API response parameter.
I'm guessing it was just trying to "help" a person uploading a key if they did a bad copy pasta or similar. That's the first piece.
On 14/10/2025 01:11, melanie witt wrote: that or this may have also been used in the past when we generated a key to provide them with the finger print as well as the key?
The second piece is if we wanted to remove the 'fingerprint' API response parameter, we could do that in a new API microversion.
do we even supprot that any more or did we remove that in 2.92 https://docs.openstack.org/nova/latest/reference/api-microversion-history.ht... as of zed we nolonger supprot generating keypairs server side, we only supprot uploading an existing key. i geusse we didnt remove ti https://docs.openstack.org/api-ref/compute/#id240 long term i would like to remove the keypair api form nova entirly and add it to keystone. in my dream world keystone user would have keypair registered and you woudl be able to use an ssh key to auth to keystone to get a token. nova would also supprot using the same keyapir form keyston to inject into the instance as we do today via cloud init but it would not be stored in nova anymore. the ssh keypair is really the only user owned data that nova stores today the rest is all project owned. if we were adding it today it woudl have either been in keystone or barbican not nova so if we are evolving this api in the future i think we shoudl consider moving it to a more suitable service then nova. perferable keystone but that just because i really really woudl like to be able ot login to opensack with an ssh key.
-melwitt
[1] https://github.com/openstack/nova/blob/8b81b5f91ffe1f9c38a483d151b82316d443d... [2] https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization...