Mailinglist Archive: opensuse-features (201 mails)

< Previous Next >
[openFATE 300754] Key Management for YAST / Zypper / Updaters
  • From: fate_noreply@xxxxxxx
  • Date: Tue, 21 Apr 2009 15:17:21 +0200 (CEST)
  • Message-id: <feature-300754-56@xxxxxxxxxxxxxx>
Feature changed by: Christoph Thiel (cthiel1)
Feature #300754, revision 56
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
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.
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.
Requester: Mandatory
Projectmanager: Important

- openSUSE-11.2: Evaluation
+ 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
Requester: Mandatory

+ openSUSE-11.3: New
+ Priority
+ Requester: Important

Requested by: Marcus Meissner (msmeissn)

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
* 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.


Documentation Impact:
Needs Documentation in Admin guide.

#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
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
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
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

#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
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
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
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
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

#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:
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.
* 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.

openSUSE Feature:

< Previous Next >
This Thread
  • No further messages