Control: reassign 1100958 gpgv Control: retitle 1100958 gpgv does not consider RIPEMD160 and SHA-1 as weak digests Control: found 1100958 2.4.7-15 Control: found 1100958 2.2.46-6 Control: found 1100958 2.2.40-1.1
Hi Guillem--
On Fri 2025-03-21 01:28:40 +0100, Guillem Jover wrote:
> On a minimal chroot, after installing gpgv, sopv-gpgv and
> debian-keyring, when downloading a source package currently affected
> by the SHA-1 keys in the Debian keyring, sopv-gpgv does not fail to
> verify the signatures as would be expected
I'm not sure what "as expected" means here. sopv is intended to
indicate whether the underlying OpenPGP implementation accepts at least
one data signature over a given message from a set of acceptable
signers. i don't think the sopv interface itself contains any strict
requirements about specific algorithmic requirements (though each sopv
implementation might itself make decisions about what algorithms to
accept).
> ,---
> $ sudo apt install debian-keyring gpgv sopv-gpgv
> $ apt source --download-only file
> $ k=/usr/share/keyrings/debian-keyring.gpg
> $ sopv inline-verify $k <file_*.dsc >/dev/null
> $ echo $?
> 0
> $ gpgv --keyring $k --weak-digest SHA1 file_*.dsc
> gpgv: Signature made Thu Mar 13 20:46:00 2025 CET
> gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: No public key
> $ echo $?
> 2
> `---
This example seems to evaluate gpgv's return code to evaluate the
validity of the signatures supplied.
But evaluation of gpgv's return code is insufficient for assessing the
correctness of a signature. ☹ This is a common problem with using gpgv,
as the gpgv developers have indicated that the only reliable way to get
the kind of semantic detail desired out of gpgv is to parse and
interpret the "status" output.
The test transcript shown above doesn't show that kind of status
information (indeed, it doesn't even ask for it from gpgv) so it's hard
to know what the complaints seen on stderr actually mean. for example,
there could be two signatures in the file_.dsc; one of them could have
been valid, and the other one could be made by an unknown certificate.
and the warning about SHA1 signatures could have applied to an entirely
unrelated certificate in the keyring in question.
> I guess sopv-gpgv, is missing passing «--weak-digest SHA1
> --weak-digest RIPEMD160» to gpgv. This works fine when using gpgv-sq,
> because of its own defaults. :)
I don't think that sopv-gpgv should manually set these kinds of defaults
-- rather, i think it should reflect the behavior of the underlying gpgv
tool. If parsing the status output of gpgv suggests that a signature is
invalid, then it sopv-gpgv should fail. if gpgv says that the signature
is OK, then sopv-gpgv should agree. (note that signatures made over MD5
all report ERRSIG on the --status output by default; and adding
--weak-digest SHA1 makes signatures that use MD5 produce ERRSIG on the
--status output that would otherwise have showin VALIDSIG and GOODSIG)
If those defaults should be be changed in gpgv (not an unreasonable
request!) then that's something that should be raised in the gpgv
package, not in the sopv-gpgv package.
So, i'm reassigning this bug report to gpgv, as all versions of gpgv in
debian currently are willing to accept SHA1-based signatures (even those
made in 2025!)
If you think it belongs on sopv-gpgv, feel free to re-assign it back,
but please provide some explanation there.
Regards,
--dkg
signature.asc
Description: PGP signature
