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

[Jakob Bohm]

On 2024-08-05 20:08, Björn Persson wrote:
> 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.

For issues such as the above, the proper script-friendly solution is to
enhance gpgv itself with command line options to specify the desired
trust requirements.  For the multi-signer scenario above, an option could
be set to

     --must-match-percent 90 --ignore-unknown

, for the case of validating Debian whole-archive signatures that occasionally
contain both the current and future signature as part of a transition to a new
ftp-master signing key, the option could be set to

     --must-match-percent 100 --ignore-unknown --pubring /usr/share/.../current-keys.gpg





Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded