Yeah, I never understood the weird way signature verification is handled in the current guidelines ... makes sense to me to allow keys to come from a shared package that is pulled into instead of having to add things to all packages separately. +1

I can't think of any security concerns that are alleviated by doing it this way, so I guess the intent is just to avoid maintainers checking blocks of data into git. I think it would work well to just turn the "must do it this way" into "don't do the thing you shouldn't do" and we'd be fine, but even then, what would be the real harm if those files were checked in? They aren't huge. Can we just drop this language and let maintainers do what they think is best?

@rombobeorn since he originally authored this section.

I can't think of any security concerns that are alleviated by doing it this way, so I guess the intent is just to avoid maintainers checking blocks of data into git. I think it would work well to just turn the "must do it this way" into "don't do the thing you shouldn't do" and we'd be fine, but even then, what would be the real harm if those files were checked in? They aren't huge. Can we just drop this language and let maintainers do what they think is best?

Doing the same thing almost 400 times seems unreasonable (no matter how easy it is to do) :sweat_smile:

I am more interested in future maintenance though: when the keyring changes (a new key gets added), if it's in just one package I only need to update one place :-)

For reference, kde-release-keyring review request :-)

tibbs wrote:

@rombobeorn since he originally authored this section.

Thanks for the ping, but I can't take credit for the whole section.
Large parts of the text were written before I got involved. I wrote the
shellscript, made various adjustments, and expanded the policy on how
to obtain the keys. The quoted paragraph has changed very little from
this version by @dwmw2:
https://fedoraproject.org/w/index.php?title=3DPackagingDrafts:GPGSignatures=
&oldid=3D439919

The word "must" was written by @till:
https://fedoraproject.org/w/index.php?title=3DPackagingDrafts:GPGSignatures=
&diff=3Dprev&oldid=3D443252

The requirement has roots in the very first draft by @mdomsch:
https://fedoraproject.org/w/index.php?title=3DPackagingDrafts:GPGSignatures=
&oldid=3D179480

There is some security benefit to storing keys in the Git repository
instead of the "lookaside cache" (which is not a cache by the way). If
there were some weakness in the code that fetches files from the
lookaside repository, then an attacker might be able to inject a
malicious tarball and signature, but the key in Git would be
unaffected, so the verification would fail and the attack would be
thwarted.

@tmz and @dwmw2 argued that having the key in Git also makes it more
obvious when it changes:
https://pagure.io/packaging-committee/issue/610#comment-144447
https://pagure.io/packaging-committee/issue/610#comment-144440

All of that assumes a keyring in each package though. Those arguments
are only about the choice between the Git repository and the lookaside
repository. The possibility of a separate keyring package was never
considered before as far as I know.

So would keyring packages be good or bad for security? Having thought
about it for a while, I think it could go either way, depending on how
they're maintained. Packagers being insufficiently paranoid about key
changes is probably the second greatest weakness of Fedora's source
file verification (the greatest being all the upstreams that don't sign
their releases). Thus it could be an improvement if multiple packagers
would rely on a keyring package that is carefully maintained by a
maintainer who understands key management. On the other hand it could
create more opportunities for attackers, if the keyring maintainer adds
keys too readily and other packagers assume that all the keys in the
keyring package are trustworthy.

I think keyring packages can be allowed, but there should be a policy
on how they shall be maintained and used. The policy should make it
clear that the maintainer of the keyring package and the maintainer of
the using package both have a duty to ensure that only the right keys
are trusted.

marcdeop wrote:

For reference, kde-release-keyring review request :-)

Thanks. I see it contains separate key files and also a big keyring
with all the keys. Is the idea that some packages will trust signatures
from any KDE member, and other packages will trust one or a few keys
that sign the sources of that package? Trusting all the keys may be
appropriate if any member of the KDE project may make a release of any
KDE component, but is that how the KDE project is run?

I prefer separate key files because it's easier to audit changes that
way. Comparing the contents of two keyrings to see which keys have
changed is much more difficult than a recursive diff.

In KDE's key repository I find this statement:

This keyring is intended to include all keys that have been used at some =
point or another for releasing KDE software (not just currently in use keys=
).

That's quite unacceptable. It must be possible to distrust a
compromised key. Old keys should also be dropped when they're no longer
needed. Don't assume that everyone always succeeds at securely erasing
their disks before throwing them out.

Dropping old keys is easy when keyrings are included in each package.
Old source packages and Git branches still contain the keys they need,
so rebuilds continue to work. With a separate keyring package it
becomes necessary to think more carefully about when an old key can be
dropped. How long should rebuilds of an old package continue to work
with a newer keyring package? When is it acceptable for rebuilds to
need an old version of the keyring package? Should dependencies on the
keyring package be versioned to help with this? This needs to be
thought through if a policy on keyring packages will be written.

tibbs wrote:

what would be the real harm if those files were checked in?

You mean the signature? No real harm that I can see. Signatures can be
either in the Git repository or in the lookaside repository, but it's
probably most practical to keep a tarball and its signature together as
you'll normally replace both a the same time. That's beside Neal's
point though.

That's quite unacceptable. It must be possible to distrust a
compromised key. Old keys should also be dropped when they're no longer
needed. Don't assume that everyone always succeeds at securely erasing
their disks before throwing them out.

Distrusting a key is easy enough, we just delete it and respin the package. That is not a part of the workflow I'm worried about. If there's a reason to distrust a key, it can be done.

You mean the signature? No real harm that I can see. Signatures can be
either in the Git repository or in the lookaside repository, but it's
probably most practical to keep a tarball and its signature together as
you'll normally replace both a the same time. That's beside Neal's
point though.

I actually prefer to put the tarball and its detached signature in the lookaside myself.

Neal Gompa wrote:

If there's a reason to distrust a key, it can be done.

One key in kde-release-keyring was revoked before the package was even
made. Revocation is the owner saying "stop trusting this key".

Two other keys are expired, so it's doubtful whether those keys will
ever sign any future releases.

Trusting all the keys may be
appropriate if any member of the KDE project may make a release of any
KDE component, but is that how the KDE project is run?

Well... yes.

There are normally a few individuals who do the releases but technically any KDE dev can do them. Note also that some KDE packages do not follow the standard Frameworks/Plasma/Gear schedules and, thus, will likely be done by whichever KDE dev does that package release.

Friendly bump here...

is there anything I can do to move this forward in any direction?

We have added the .sig files to all our Frameworks and Plasma packages (Gear is still missing).

Our scripts already do the gpg validation on our updates but I would like to add the validation on the spec files as well :-)

Getting this resolved would make things way easier for us.

Thanks in advance!

Marc

To move this forward, I suppose somebody needs to submit a merge request with a proposed change to the policy. I naturally think the proposal should address the points I made above.

The fact that kde-release-keyring still contains the revoked key I mentioned indicates that the policy needs to contain some very strict and detailed rules about removing revoked and expired keys from keyring packages.