Daniel Kahn Gillmor via Gnupg-users wrote: > On Mon 2024-07-29 15:47:09 -0400, Todd Zullinger via Gnupg-users wrote: > > Using /usr/lib/rpm/redhat/gpgverify -- which is a small > > shell script wrapper for gpgv -- avoids new dependencies and > > produces quite readable output which is handy in build logs. > > is this the source for gpgverify that you're using? > > https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/main/f/gpgverify
That's it, and this is its author speaking. > This depends explicitly on the return code for gpgv, which is known to > be brittle. (it also depends on gpg itself, not just on gpgv, as you > noted earlier, for the dearmoring) The gpg2 and gpgv2 commands are both provided by the gnupg2 package, so they count as a single dependency on the package level. > For example, if the detached signature contains multiple signatures, and > gpgv can't verify one of them, it will return a non-zero error code, > even if it *can* verify the other signature. It's true that requiring verification of all the signatures is not always desirable. Allowing all but one to fail is not always right either. Deciding how many correct signatures should be required is nontrivial. I doubt any general verification tool can automatically do the right thing in every case without parameters telling it what's desired in the specific usecase. Consider Bitcoin Core as a case study. (Everybody please set aside any opinions you may have about cryptocurrencies, and focus on the source code verification.) The Bitcoin Core developers have moved away from a single release-signing key. They don't want a single central point that an attacker could compromise. Release tarballs are instead signed by multiple individuals, each with their own personal key. The set of signers varies from release to release. Users – or package maintainers in the case of packaging in distributions – aren't required to trust all the signers. They're expected to choose a few individuals who they deem trustworthy, and import their keys. If one downloads a new release of Bitcoin Core, and one signature is good but none of the others match the tarball, that's almost certainly a malicious tarball and the one matching signature is made by the attacker. The situation should be investigated with extreme suspicion. gpgv would return failure, which is correct in this case. sopv-gpgv would return OK because one signature could be verified. That's very bad. To work around this and return failure in this case, it would be necessary to write some kind of wrapper around sopv-gpgv – but a wrapper around a wrapper would be unnecessary complexity. If nine out of ten signatures are good, and the tenth is made with an unknown key, that's not cause for alarm. That tarball should be considered verified. sopv-gpgv would return OK, which is good in this case. gpgv would return failure, which is not optimal. A possible workaround would be to manually remove the signatures by unknown keys and verify the rest with gpgv. That's doable because the Bitcoin Core signatures are separately ASCII-armored and then concatenated into a single signature file. If gpgv says there's no key for the fifth signature, then delete the fifth ASCII-armored block from the file. That's not great, but should be workable to a packager with a basic understanding of signature verification. Ignoring signatures made with unknown keys, but raising an alarm for any signature that doesn't match the signed file, would not always be right either. If there is a group of trusted developers who usually sign every release, and then one day all but one of the signatures are from unknown keys, that's also cause for suspicion. So gpgv has a limitation, and sopv-gpgv has a limitation, but sopv- gpgv's limitation would be worse for a distribution's security. > This means every tool that > depends on gpgverify is going to make it difficult to migrate the > ecosystem to new cryptographic algorithms. > > The usual approach for that would be to sign the file with both the old > and new algorithms, and put them both in the detached signature file. > That way, existing implementations can continue to verify the old > algorithm, and newer implementations can verify the new one. I don't remember ever seeing an example of that approach. As far as I can tell, the usual approach is to have verification tools support both old and new algorithms. Signers switch keys and signatures to the new algorithm when they think support for it is sufficiently widespread. Then support for the old algorithm is removed from tools when almost nobody uses it anymore. Björn Persson
pgpJ2aUV9YzKA.pgp
Description: OpenPGP digital signatur
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
