[gnutls-devel] GnuTLS | Discussion: tarball signing practice (#1407)

[Read-only notification of GnuTLS library development activities]

Andreas Metzler commented:


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

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1407#note_1145518090
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20221023/1b7e2c1a/attachment.html>