Bug 1184808

The basic idea:

- Inside the signed repodata.xml one can list additional gpg keys which should be
suggested to be imported along with the key signing the metadata.

  [repomd.xml]
    <repomd>
      <tags>
        <content>gpg-pubkey-0dfb3188-41ed929b.asc</content>
      </tags>
      <data ....

We'd expect a tag matching:

    gpg-pubkey-{KEYID}-.*

to denote an (optional) file in the repos root containing an ascii armored key with ID
{KEYID}. If key {KEYID} is not already in the rpmdb, we'd try to download the file. 

If it actually contains a key with this ID, we'd ask whether the user wants to trust and import the key like we do for the key signing the metadata.

So the filename mentioned in the repodata.xml contains the short key-id
consisting of 4 bytes and then something that I don't know that it is, so in
your example 41ed929b, what is this referring to?

I understand that repodata.xml is already trusted via signature so any
recommended keys listed in there can be trusted. However using only the short
key-id is not good enough in my opinion. Ideally the full key fingerprint
would be contained in the repodata.xml. If that was the case then the keys
could even be automatically imported, since they are integral part of the
repository description.

Ideally there would also be some check implemented that the to-be-imported
keys match minimum cryptographic standards. Importing decade old 1024-bit DSA
keys might not be the best idea. Also revoked keys should be rejected and what
about expired keys? It looks like we need to support these.

Usability should also be kept in mind ... for example during openSUSE desktop
installation I remember this dialog whether I want to trust some nvidia gpg
key. How should the user know whether to trust that when it is in the middle
of an installation procedure?

normally this is intended as a reference to the key file that resides in 
the same file tree (ftp or media) that the repomd.xml file is in, usually
it is

/gpg-pubkey-$ID-$TS.asc
/repodata
/repodata/repomd.xml

as for the IDs in the filename, the second one is the timestamp of the
most recent expiry signature of that key, the naming comes from rpm and
this is exactly how the key appears in the rpm database if you import
a gpg pubkey into the database:

rpm -q gpg-pubkey
[...]
gpg-pubkey-39db7c82-5f68629b

rpm -q gpg-pubkey-39db7c82
gpg-pubkey-39db7c82-5f68629b

rpm -qi gpg-pubkey-39db7c82
Name        : gpg-pubkey
Version     : 39db7c82
Release     : 5f68629b
[...]
(and then the pgp public key block)

and then:
rpm -qi gpg-pubkey-39db7c82 | gpg --list-packets
# off=0 ctb=99 tag=6 hlen=3 plen=269
:public key packet:
        version 4, algo 1, created 1359648363, expires 0
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        keyid: 70AF9E8139DB7C82
# off=272 ctb=b4 tag=13 hlen=2 plen=40
:user ID packet: "SuSE Package Signing Key <build@suse.de>"
# off=314 ctb=89 tag=2 hlen=3 plen=316
:signature packet: algo 1, keyid 70AF9E8139DB7C82
        version 4, created 1600676507, md5len 0, sigclass 0x13
        digest algo 2, begin of digest 54 1c
        hashed subpkt 27 len 1 (key flags: 03)
        hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
        hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3)
        hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
        hashed subpkt 30 len 1 (features: 01)
        hashed subpkt 23 len 1 (keyserver preferences: 80)
        hashed subpkt 2 len 4 (sig created 2020-09-21)
        hashed subpkt 9 len 4 (key expires after 11y234d16h15m)
        subpkt 16 len 8 (issuer key ID 70AF9E8139DB7C82)
        data: [2048 bits]


(and "created 1600676507" just happens to be 5f68629b in hex)

(In reply to Matthias Gerstner from comment #2)
> I understand that repodata.xml is already trusted via signature so any
> recommended keys listed in there can be trusted. However using only the short
> key-id is not good enough in my opinion. Ideally the full key fingerprint
> would be contained in the repodata.xml. 

@Rudi: In this case we had to extend the entry. What about an URL like notation, so we'd be free to extend it to look at arbitrary remote locatios:

  gpg-pubkey-3dbdc284-53674dd4?fpr=22C07BA534178CD02EFE22AAB88B2FD43DBDC284


> If that was the case then the keys
> could even be automatically imported, since they are integral part of the
> repository description.

No, we don't plan to import any key automatically. 
All keys will be presented to the user and have to be confirmed.


> Ideally there would also be some check implemented that the to-be-imported
> keys match minimum cryptographic standards. Importing decade old 1024-bit DSA
> keys might not be the best idea. Also revoked keys should be rejected and
> what about expired keys? It looks like we need to support these.

That's also one of the reasons why we do not want to automatically judge any key. We follow rpms behavior - keys imported in the DB are trusted, others not. 
If a key has expired, this does not invalidate packages which have been signed with it. If the rule should be changed, we had to start with rpm.

We show the data we know about the key, but the user has to confirm its usage.


Currently displayed:

  Repository:       repo-oss
  Key Name:         openSUSE Project Signing Key <opensuse@opensuse.org>
  Key Fingerprint:  22C07BA5 34178CD0 2EFE22AA B88B2FD4 3DBDC284
  Key Created:      Mon 05 May 2014 10:37:40 AM CEST
  Key Expires:      Thu 02 May 2024 10:37:40 AM CEST
  Rpm Name:         gpg-pubkey-3dbdc284-53674dd4
  
  (zypper: expired keys or those about to expire are shown upon repo 
   refresh (all repo keys if --verbose))


The next zypper version will include the algortithm and maybe a [19x11] fingerprint visualization: 
[https://github.com/openSUSE/libzypp/blob/master/zypp/base/DrunkenBishop.h]

[openSUSE Project Signing Key <opensuse@opensuse.org>]
 +----[RSA 2048]-----+
 |   .^ ^            |  fpr 22C07BA534178CD02EFE22AAB88B2FD43DBDC284
 |     ^ ^           |   id B88B2FD43DBDC284
 |  . .   .          |  alg RSA 2048
 |   : : ^           |  cre 1399279060 Mon May  5 10:37:40 2014
 |  . l l            |  exp 1714639060 Thu May  2 10:37:40 2024
 |   ^ : . S         |  ttl 1108
 |  . l ^ .          |  rpm 3dbdc284-53674dd4
 | ^ E l .           |
 |^ . : . .          |
 |l    ^ .           |
 |?l.   .            |
 +----[3DBDC284]-----+



Next may be more info about the keys that have signed it...




> Usability should also be kept in mind ... for example during openSUSE desktop
> installation I remember this dialog whether I want to trust some nvidia gpg
> key. How should the user know whether to trust that when it is in the middle
> of an installation procedure?

That's IMO why the issuer of a repo should be enabled to ship additional keys which are used to sign packages or related repos in advance.

if we want to add this tell me.
to keep the thought:
gpg --with-colons --import-options show-only --import --fingerprint < gpg-pubkey-b04a477b-5d2d7480 2>/dev/null | grep ^fpr | cut -d: -f10

(In reply to ma@suse.com from comment #4)
> > If that was the case then the keys
> > could even be automatically imported, since they are integral part of the
> > repository description.
> 
> No, we don't plan to import any key automatically. 
> All keys will be presented to the user and have to be confirmed.

As a security minded person I can of course see the trouble with automatically
trusting keys. However in this case it is about our very own SUSE keys that
are referenced in a repository description that is secured with our current
main repository key. If I understand the original bug report correctly then it
will be a kind of default situation that packages signed with the older/other
keys will appear. Does it really make sense to bother the end user with the
decision whether to trust these keys?

Which again brings me to the question: Based on which criteria do you think
will or can an average end user decide whether to trust these keys or not?
Will this be any better than an arbitrary decision? Will we not only train end
users to click "yes" all the time when confusing dialogs appear?

IMO at a minimum a reference to clear documentation would be necessary that
explains the meaning of these keys and how to verify them.

well, "it is about our very own SUSE keys" is IMHO simplifying things a bit
too much. The different keys are there because the packages come from
different projects with different groups of reviewers and different processes.

In this case we talk about SLE vs openSUSE vs Backports and each has a completely
different background.

(In reply to ro@suse.com from comment #7)
> In this case we talk about SLE vs openSUSE vs Backports and each has a completely
> different background.

That may be the case. But what does that mean with regard to trust? Don't we
trust the backport key, for example? Do we trust it in our SLE releases by
default?

For me the main question remains based on what criteria an end user is
supposed to decide whether to trust these keys or not. Because only if an
informed decision can be made can it make any sense, or am I missing something
here?

Johannes raised the question whether this mechanism could also be used by
third-party repositories or random repositories in OBS to "smuggle in keys".
Will this be possible?

> Do we trust it in our SLE releases by default?

no, we do not. Backports is basically "the part of Leap that is not part of SLE",
the packages in Backports are not part of our SLE product line. And the Backports key is not added as a trusted key during a SLE product installation by default.

(In reply to Matthias Gerstner from comment #8)
> For me the main question remains based on what criteria an end user is
> supposed to decide whether to trust these keys or not. Because only if an
> informed decision can be made can it make any sense, or am I missing
> something here?

As far as I can tell from support and communications with customers it's not so much the question whether to trust the keys or not. But they want to know when and why a new key was imported.

I'd agree with auto importing those keys, if the scope of the key was the repo that ships it. But once the key is imported into the rpm database it is not. The imported key will be able to verify packages and metadata from arbitrary repos.

The question is not if we trust the backport key, or any other of our own keys. The feature is common, so any repo provider will able to use it. People 'trust' Packman or OBS repos (specially home: projects) , because they want some packages from there. Not sure if they'd expect this to be a complimentary ticket for importing trusted keys by solely looking at the repos content. 
But this is what it would be if we'd silently import included keys.

(In reply to Matthias Gerstner from comment #6)
> IMO at a minimum a reference to clear documentation would be necessary that
> explains the meaning of these keys and how to verify them.

What about putting this into the hands of or webpages (suse/opensuse). Don't we have a page that lists our keys and their fingerprints (maybe including the same asciiart zypper could show, provided it actualy eases comparing fingerprints). 

Wouldn't this be a good place to have some common words about those keys. I would not mind to include such a link in the zypper output (and I guess the YAST guys won't either).

(In reply to Matthias Gerstner from comment #9)
> Johannes raised the question whether this mechanism could also be used by
> third-party repositories or random repositories in OBS to "smuggle in keys".
> Will this be possible?

Of course if we don't ask for confirmation.

I'd ask soemthing like

  The repo FOO signed by the (trusted) FOOKEY suggests to trust and import
  those additional keys:
      ...
  Most probably these additional keys were used to sign packages shipped by
  the repo. But we can't tell this for sure.

  If you don't want those keys we will keep them in /var/cache/zypp/pubkeys in
  case they are needed later and you change your mind.

(In reply to Michael Andres from comment #13)
For me this means that we have to ask for confirmation, no matter how useful this might be for a vast majority of customers

Thanks for all the clarification. So it looks like explicit confirmation is
required and documentation should be added to make the context clear to users.
The text in comment 13 goes into the right direction. An additional URL
reference to where SUSE specific keys can be verified would be perfect.

(In reply to Matthias Gerstner from comment #15)
> The text in comment 13 goes into the right direction. An additional URL
> reference to where SUSE specific keys can be verified would be perfect.

If there is such an URL, please let me know.

(In reply to ma@suse.com from comment #16)
> (In reply to Matthias Gerstner from comment #15)
> > The text in comment 13 goes into the right direction. An additional URL
> > reference to where SUSE specific keys can be verified would be perfect.
> 
> If there is such an URL, please let me know.

Sadly it looks like there is no up to date suitable public URL existing that
documents our keys. Introducing one will probably take a longer time and the
question also is who would be responsible for creating it and maintaining it.

I could create a page in the openSUSE wiki but I am not sure if that is a
suitable approach.

(In reply to Matthias Gerstner from comment #17)
> Sadly it looks like there is no up to date suitable public URL existing that
> documents our keys. Introducing one will probably take a longer time and the
> question also is who would be responsible for creating it and maintaining it.

I don't know who is the MASTER of our keys (but I hope there is one). 

IMO the one/team who owns a private keys should somehow track it on a public page. Don't we SUSE/openSUSE have something like  https://getfedora.org/security/ ?

(Don't know if openSUSE wiki would be an appropriate place for the SLES stuff)

Just a suggestion - I do not know if this only makes it more complicated:
PGP/gpg is about the web of trust.

Would it be possible and make sense that the openSUSE package signing key signs(=trusts) the SUSE package signing key and then the SUSE key would automatically be imported as trusted on openSUSE?

(In reply to Dirk Weber from comment #20)
> Would it be possible and make sense that the openSUSE package signing key
> signs(=trusts) the SUSE package signing key and then the SUSE key would
> automatically be imported as trusted on openSUSE?

Basically yes, but not as 'quick' fix now.

We're already working on a 'zypper keys' command to support viewing and managing the trusted keys. Once we have a better tool to inspect and manipulate the keys, we can think about automatism. Otherwise unwanted results or miss behavior are hard to detect and fix.

Whatever automatism we offer it needs to be configurable, and the sane default is 'none'. The request/ideas so far contain a 'configurable list of fingerprints that may be autoimported'. A transitive trust, like you suggested also fits in there. But IMO one wants to define which keys are allowed to auto import keys by signing them.

(In reply to ma@suse.com from comment #18)
> IMO the one/team who owns a private keys should somehow track it on a public
> page.

Yes I guess that makes sense.

> Don't we SUSE/openSUSE have something like https://getfedora.org/security/ ?

It seems we only have it for verifying openSUSE ISO images:

https://en.opensuse.org/SDB:Download_help#Checksums

I remember that I recommended to at least make the verification easier using a
script in bug 1029564 comment 6.

(In reply to Michael Andres from comment #16)
> (In reply to Matthias Gerstner from comment #15)
> > The text in comment 13 goes into the right direction. An additional URL
> > reference to where SUSE specific keys can be verified would be perfect.
> 
> If there is such an URL, please let me know.

Our SLES keys are documented here:

https://www.suse.com/support/security/keys/

We could also list openSUSE keys here.

(In reply to Ruediger Oertel from comment #5)
> if we want to add this tell me.
> to keep the thought:
> gpg --with-colons --import-options show-only --import --fingerprint <
> gpg-pubkey-b04a477b-5d2d7480 2>/dev/null | grep ^fpr | cut -d: -f10

@Rudi: It won't hurt to add this, even if the full fingerprint is optional.

  gpg-pubkey-3dbdc284-53674dd4.asc?fpr=22C07BA534178CD02EFE22AAB88B2FD43DBDC284

done, submitted to factory/tumbleweed and to leap-15.3

The review aspect for this is complete I guess. Regarding documentation we
approach our documentation team to make them aware and to see whether they can
improve something here. Closing.

Update:

- As suggested in c#6, additional keys identified by the fingerprint will be displayed, but auto imported without IFF the repo metadata file was validated by a trusted key.

- https://bugzilla.suse.com/show_bug.cgi?id=1184326#c54
That's a kind of stopper. If https://download.opensuse.org/ is used as repo url, we may not get the gpg-pubkey files downloaded. download.opensuse.org redirects https->http, but libzypp does not follow such redirects. 
The only workaround I see would be to add an exception for download.opensuse.org and follow http redirects from there.

(In reply to ma@suse.com from comment #27)
> - https://bugzilla.suse.com/show_bug.cgi?id=1184326#c54
> That's a kind of stopper. If https://download.opensuse.org/ is used as repo url, we may not get the gpg-pubkey files downloaded. download.opensuse.org redirects https->http, but libzypp does not follow such redirects. 
> The only workaround I see would be to add an exception for download.opensuse.org and follow http redirects from there.

What exactly is the question? Whether it is a good idea to retrieve a GPG key
from an http:// URL for verification of repository trust?