Feature changed by: Andreas Jaeger (a_jaeger) Feature #300754, revision 66 Title: Key Management for YAST / Zypper / Updaters openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-10-17 10:57:07 reject reason: Yes, we need better GPG key management, but not as additional module, but integrated in the parts who add installation sources. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-04-15 10:34:32 reject reason: Missing input from security team. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-31 15:24:49 reject reason: Out of resources. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-21 15:16:11 reject reason: Needs to be discussed for 11.3 Priority Requester: Mandatory openSUSE-11.3: Evaluation by project manager Priority Requester: Important Info Provider: (Novell) + Info Provider: (Novell) Requested by: Marcus Meissner (msmeissn) Developer: (Novell) Description: On GPG key import (when adding package repositories) we currently just show the key id and the fingerprint of the key. We need better key management and this could be done in a new YAST Module, which could do things like: * Key import from disk or from network (keyservers preset/configurable). * On key import, show fingerprints and allow to browse signatures (also showing which are already trusted or not), and expiry dates. * Key removal / remove trust possible. Design should be worked on together with the security team. References: https://bugzilla.novell.com/show_bug.cgi?id=186764 https://bugzilla.novell.com/show_bug.cgi?id=115485 Documentation Impact: Needs Documentation in Admin guide. Discussion: #1: Edith Parzefall (emapedl) (2006-09-05 12:02:06) Jiri, do you have some one for the YaST module? #2: Edith Parzefall (emapedl) (2006-09-05 12:02:48) Adding Duncan as technical contact. #8: Ladislav Slezak (lslezak) (2008-01-17 15:17:07) The GPG key manager is part of the repository manager, submitted in yast2-packager-2.16.15 The current key manager displays a table with all trusted keys and user can do: * import a GPG key from a file * remove a GPG key from the trusted keyring * display details about a key (fingerprint, creation and expiration dates) It doesn't support/display untrusted keys because they do not have a persistent storage (the trusted keys are stored in the RPM DB), all untrusted keys are lost at exit, so it doesn't make sense to work with them. The popup displayed when importing a GPG key now displays creation and expiration dates. If the key is expired there is a warning message. Is that functionality sufficient or do we need to be able to fetch a key from a keyserver? Do we really need to browse all signauters of the key? #9: Marcus Meissner (msmeissn) (2008-02-25 17:50:02) (reply to #8) Sorry, I did not yet have the time to review this (and install Alpha2+)... Will get back to you as soon as I find testing time. #10: Marcus Meissner (msmeissn) (2008-03-19 17:37:29) (reply to #8) I just now had a look at Alpha3. It is not sufficient I am afraid. On adding a new repositories, just before this import dialog, the list of signatures should really be shown. What I had in mind: - in the "import key" dialog, offer the list of signatures. - show GPG signatures from keys that we know as "good" somehow. -> signatures for keys already in RPMDB -> [locally trusted key] -> signatures for SUSE specific ones (from root? rpm? keyring= -> [SUSE trusted key] -> others [untrusted key] Its quite more than there currently is. Hmm #15: Federico Lucifredi (flucifredi) (2008-06-12 17:16:47) Marcus, please let me know whyat above and beyond the 11.0 status is desired, if any. #16: Marcus Meissner (msmeissn) (2008-06-13 22:43:12) (reply to #15) Partially / Half done. We have not found a fully good solution, this needs direct communication with the YAST2 developer and the security team, perhaps during the YAST2 workshop. And we also should review of how the current code is used and accepted by users in 11.0. So we will revisit for 11.1. #17: Federico Lucifredi (flucifredi) (2008-06-13 18:06:48) (reply to #16) okie, giving it an Important for now then. #21: Ludwig Nussel (lnussel) (2008-07-18 10:13:32) please reconsider priority of this feature with the current hype about package management security in mind. #25: Duncan Mac-Vicar (dmacvicar) (2009-01-08 16:36:49) Basic key management is already there. Federico, what is Important for PM here? which concrete functionality? #26: Federico Lucifredi (flucifredi) (2009-01-08 14:48:09) (reply to #25) From my point of view, I would like trust to be terminated when removing a repo from the subscribed list (i.e. also removing the keys previously approved). Kurt was at the origin of this feature, we may also want to hear from him on the current state (adding needinfo). #27: Duncan Mac-Vicar (dmacvicar) (2009-01-09 17:51:27) (reply to #26) Ok, some input would be needed: * What happens if the repo was originally signed with one key, which was trusted, and then the key changed, this one was trusted too? * Multiple repos signed with the same key? I feel the approach is some kind of reference count? But that means that if the user removes all repo, he will even get rid of the build key. #28: Kurt Garloff (garloff) (2009-01-09 19:11:01) (reply to #27) When judging the trustworthiness of a new key, the signatures of a key should be displayed -- limiting the display to signatures with keys that we already trust would be OK, from my POV. An option to automatically trust a new key if it's signed with an already trusted key would also be a good thing to have, this way allowing to use a hierarchical CA model of trust if the user wants so. It could be a global flag, but better would be per key: "Trust every key that has been signed by this key." Actually, I think we should have such trust chains -- there could be a SUSE master key that's trusted by default and then packages get signed with different keys, depending on where we build them (Provo, abuild, ...). There could be a master key for all OBS repos (though I personally would not enable "trust all keys signed by this"). (Note: I know that full trust chains would walk a signature chain and check recursively ... we can do that as well, but it's a bit more complicated with GPG. But as RPMs are signed with GPG keys, I think it's not a good idea to mix that with openssl (X.509) certificates ...) Duncan -- I would indeed think that the ref counting that you mention is the way we would want to handle this. When you have a key that's not used by any repo any longer, the admin should be offered to remove it from the list of trusted keys (and I would think we should default to remove). Same for keys that have expired. I think our security folks should drive the requirements here -- and someone needs to complement their view from a usability perspective. (A security feature is useless if everybody switches it off because it's an annoyance ;-)) Note: We've had 2 years of time to sort this :-( #29: Duncan Mac-Vicar (dmacvicar) (2009-01-16 15:19:30) Repository keys/signatures meeting 15.01.2009 present: dmacvicar, draht, lnussel, meissner How current model works: http://en.opensuse.org/Libzypp/Metadata_Signature How to solve? 1) amount of key imports and confirm dialogs (ie: NVIDIA) (less dialogs the better 2) Usability of the dialog. Nobody reads the fingerprint and therefore dialog is useless. 3) feature #300754 requirements Item 3 has the following requirements: 1) transitive trust 2) removal of keys Feasible solutions for 11.1: * Would be solved by 3.1) allowing SUSE to sign NVIDIA's key and utomatically trust with 1 level. * Show the fingerprint in a easy to compare way (*) Making fingerprints easy to compare: * randomart (openssh's key_fingerprint_randomart ) * "Hash Visualization: a New Technique to improve Real-World Security", Perrig A. and Song D., 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99) sparrow.ece.cmu. edu/~adrian/projects/validation/validation.pdf * bubblebabble / diceware? (ie: `1234567890' is`xesef-disof-gytuf-katof- movif-baxux' ) * We need to tell when the key changed explicitly. * 3.1 will be used to solve 1). 3.2 as described by PM has no benefit from security point of view, and manual management of the keys is already possible. + #31: Andreas Jaeger (a_jaeger) (2010-11-16 12:16:11) (reply to #29) + These are old minutes - how do we want to move forward? -- openSUSE Feature: https://features.opensuse.org/300754