Home_greyopenFATE - openSUSE feature tracking > #300754
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Key Management for YAST / Zypper / Updaters

Feature state

openSUSE-10.2
Rejected Information
openSUSE-11.0
Rejected Information
openSUSE-11.1
Rejected Information
openSUSE-11.2
Rejected Information
openSUSE-11.3
Rejected Information

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


icons/user_comment.png E. P. wrote: (11 years ago)

Jiri, do you have some one for the YaST module?

icons/user_comment.png E. P. wrote: (11 years ago)

Adding Duncan as technical contact.

icons/user_comment.png L. S. wrote: (10 years ago)

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?

icons/user_comment.png M. M. wrote: (10 years ago)

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.

icons/user_comment.png M. M. wrote: (10 years ago)

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

icons/user_comment.png F. L. wrote: (10 years ago)

Marcus, please let me know whyat above and beyond the 11.0 status is desired, if any.

icons/user_comment.png M. M. wrote: (10 years ago)

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.

icons/user_comment.png F. L. wrote: (10 years ago)

okie, giving it an Important for now then.

icons/user_comment.png L. N. wrote: (9 years ago)

please reconsider priority of this feature with the current hype about package management security in mind.

icons/user_comment.png D. M. wrote: (9 years ago)

Basic key management is already there.

Federico, what is Important for PM here? which concrete functionality?

icons/user_comment.png F. L. wrote: (9 years ago)

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

icons/user_comment.png D. M. wrote: (9 years ago)

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.

icons/user_comment.png K. G. wrote: (9 years ago)

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 :-(

icons/user_comment.png D. M. wrote: (9 years ago)

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.
icons/user_comment.png A. J. wrote: (7 years ago)

These are old minutes - how do we want to move forward?

Last change: 6 years ago
Voting
Score: 15
  • Negative: 3
  • Neutral: 1
  • Positive: 18
Tags
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint