sopv-gpgpv: an implementation of the verification-only subset of the Stateless OpenPGP CLI using gpgv as a backend

[Björn Persson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signatur
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240805/074d1ccd/attachment.sig>