Discussion: tarball signing practice

We recently started signing release tarballs with multiple keys. As that imposes some overhead in the release process, it might need further discussion.

• Do we want to keep this practice (multiple signatures)? What are the benefits and drawbacks?
• Is the keyring management good enough?
• Can we simplify the process by automation, e.g., by signing with a vault key shared by multiple people as in libreswan?

added triageddiscussion label

One downside of multiple signatures with the 3.7.8 release: one of the signatures on the tarball is from Alexander Sosedkin, whose key isn't in the release keyring linked from the download page (and isn't listed on the maintainers page). So, as a packager, when I import the keyring with GnuPG and then try to verify the tarball's signature, it fails because one of the signatures can't be verified even though the other two are OK. It'd be good to check that the keyring is up to date as part of the release process.

I've appended the key in web-pages@f1881d8d

Would it be a problem if we limit keys that are in the release keyring to gnutls maintainers? Even if the release is done by somebody else? That would help reduce the overhead.

As long as the release is signed by someone in that keyring, of course, then it'd be fine with me (speaking for Gentoo).

mentioned in commit gentoo/gentoo@54129afd

mentioned in commit gentoo/gentoo@b0863858

changed the description

We had a little but of discussion in Debian about this on https://bugs.debian.org/1010955 since our (Debian's) tooling is not up to this yet, we currently check whether all signatures are trusted instead of any. I think Daniel Kahn Gillmor summed up nicely why this is wrong:

[...] Requiring every discovered signature to be valid is a mistake. For example, it means that projects that start publishing an OpenPGP v5 signature (when rfc4880bis is finally released) alongside their OpenPGP v4 signatures will fail to be validated. [...] If anything, the correct move here is to have uscan be satisfied as long as it finds any valid signature from any key in the keyring located in debian/upstream/signing-key.asc.

Here's another way of looking at it: consider a malicious network adversary capable of interposing themselves and tampering with either the tarball or the signature -- it is trivial (and unavoidable) that the adversary can make a good signature fail; just fiddle some bits in the signature or the tarball. What we critically want to avoid is for them to be able to make a bad signature appear good.

But note that if we believe every supplied signature must be good when a multiple signature is supplied, and one signature is from an unknown party, then a network attacker can simply remove the unknown signature, and the remaining signatures will all pass, converting a "bad" multi-sig into a "good" single-sig. The threat model for this approach is clearly muddled!

By permitting a single signature from any signer to validate, we are not increasing the capabilities of the attacker at all. we're simply making the system more robust, and enabling upstream developers to smoothly migrate to new keys by signing with both keys for a period of time.

Extrapolating from this I also think that GnuTLS should continue to have a limited set of trusted signers (= the published keyring) with every release being signed with one of these. There might be a bigger set of people preparing releases who might also sign, but they should not be added to trusted keyring just to fullfill a wrong technical requirement (every signature trusted).

cu Andreas

fwiw, i agree with @ametzler here -- you should be able to add any number of signatures to the .sig of the associated tarball without introducing any problems. It's not GnuTLS's fault that some OpenPGP verification tooling makes poor decisions about how many signatures should be valid, and you certainly shouldn't change your workflow to accomodate that. Having a release signed by multiple keys is entirely reasonable.

A fix has been prepared for debian's tooling so hopefully this won't be an issue for debian for much longer at any rate.

Of course, none of the above should stop you from adding any OpenPGP certificate to the list of parties you think should be able to sign a release.