"Key pair" should be "public key" in several places

Bug #1758007 reported by Olaf Seibert
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Expired
Wishlist
Unassigned

Bug Description

Under the page https://..../horizon/project/access_and_security/ (you get there via Project -> Compute -> Access & Security), there are several mentions of "Key Pair": "Key Pair Name", "Import Key Pair", "Delete Key Pair", "Delete Key Pairs".

Fortunately, none of these actions are really about secret keys. They are all about public keys, so all of these mentions are wrong and should be "Public Key".

The one exception is "Create Key Pair". That option does generate a public and a private key. However, that is inherently insecure. Private keys must never leave the end-user's computer. They must certainly never be generated remotely. (See the recent issue about the SSL private keys which were archived by a certificate reseller, for instance at https://arstechnica.com/information-technology/2018/03/23000-https-certificates-axed-after-ceo-e-mails-private-keys/ ). Therefore this button and related functionality must be removed.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

This topic needs to be evaluated carefully. As summary, this should get a consensus as not horizon but the whole OpenStack community. Could you start discussion on this more broadly if you have a motivation?
IMHO we should not start renaming until the whole OpenStack community get consensus.

For more detail below.

Although what the bug description says is technically correct, but before moving this forward we must evaluate possible confusion which the renaming could bring carefully.

I see at least two confusions:
(a) Nova API [1], CLI (nova [2] and OSC[3]), OpenStack SDK [4] use "key pair", so if only horizon changes the corresponding term from "key pair" to "public key" this will brings confusion to end-users. Using two terminologies for a single concept must be avoided.
(b) "key pair" is being used from the beginning of nova and existing users are familiar with "key pair", so renaming it would bring confusions to such users.

(a) potentially includes (b).

[1] https://developer.openstack.org/api-ref/compute/#keypairs-keypairs
[2] https://github.com/openstack/python-novaclient/blob/cceab38e793967cca9f27a1576d3b71caf107cf1/novaclient/v2/keypairs.py
[3] https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/keypair.html
[4] https://docs.openstack.org/python-openstacksdk/latest/user/proxies/compute.html#keypair-operations

Revision history for this message
Olaf Seibert (oseibert-sys11) wrote :

Well, I haven't looked at discussions in a larger openstack context. My motivation for the report is mainly that I was very confused by the terminology in the dashboard! I certainly didn't want to upload any private keys to whatever server (even though it was our own) since that is against our security policy. I was relieved to see that most of these things are not actually about private keys.
That motivates my suggestion to change terminology. I suppose that old and new terms can co-exist for a while in any API context (I just took the context of the horizon dashboard into account).

Revision history for this message
Akihiro Motoki (amotoki) wrote :

This is the current status:
(1) As of now (Rocky development cycle), "Import Key Pair" is now renamed to "Import Public Key".
(2) All other appearances of "Key pair" are used consistently across Nova API/CLI and Horizon.

"Key Pair" comes from the terminology from Nova API and it is sufficient that Horizon already uses "Import Public Key".
Considering this, I wonder what should be done more in Horizon? (From this, I am marking this as Incomplete.)

Changed in horizon:
status: New → Incomplete
importance: Undecided → Wishlist
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.]

Changed in horizon:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.