-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow public key import and nicknames #1428
Comments
After further conversation, most users would have very little use with the import feature. But it may be good anyway. |
The front end will need a mapping of the public keys -> nicknames. This mapping should be the same across all organizations. The mapping should default to the owner of the key. This way, when displaying the key, it will display the user entered nickname, then the owner if no nickname, then the actual key if no owner. If either the owner or nickname is present then the key should come second and be in parentheses, giving the name precedence. |
Perhaps importing would just match the keys the app knows about with the keys in the files, then use the filename as the key nickname. |
The user will need to be able to manage the public keys stored, as we do not want to automatically remove any public keys when another user is removed from the organization. Or if the user himself is removed, we do not want to remove any mappings. This is because those keys may be present in another organization, or the user may desire to keep those keys. As this management is required, importing a list of keys would belong there, and could add keys the app does not yet know about, in addition to matching known keys. |
Users have requested to be able to import public keys in order to give them nicknames.
If the user is viewing the key on an account that has public keys that are not owned by the organization (no user has uploaded that public key to the back end, or the user is not connected to a back end and doesn't own the key or hasn't uploaded it), then the tool does not know the owner of the key. If the tool were to allow the user to upload a public key and give it a nickname, then no matter the organization selected, no matter the account being viewed, the user would be able to see the nickname of the public key wherever it appears.
Adding a subsection to keys could be a helpful way to allow the user to keep their private keys and others' public keys sorted and viewable. If not, the keys need to be very visible distinct.
The text was updated successfully, but these errors were encountered: