Hi! On Mon, 2025-04-21 at 14:27:12 -0400, Daniel Kahn Gillmor wrote: > 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
> 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). While I think I understand how SOP(V) got into not (wanting) to require specific algorithms for each different implementation (given the extensibility and optionality from OpenPGP RFC), this mean that a tool consumer of that interface then cannot get uniform results. And those depend on what implementation is currently providing the SOPV interfaces, which I think can be rather confusing for the users of the consumer tool. About having some behavior guarantees by SOP/SOPV, I think I do see a difference between, for example, supporting specific optional algorithms (which in my mind would not need to be mandated), to refusing algorithms which are supposedly considered bad security practice nowadays. If there is really no desire for some behavior baseline in SOP, then I guess it would be nice to be able to ask for it somehow. Of course what that baseline might contain, is probably a tricky question, because as the OpenPGP interop test suite shows there are many behavior differences between implementations. :) But I think very common and visible things such as whether SHA-1 and RIPEMD-160 are accepted would be something easy to settle on? > > ,--- > > $ 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. Sorry, I went for concision, mainly wanting to show that when using those flags the verification fails (not as something to use in sopv-gpgv as-is), the output would be something like the following (but that does not change my point): ,--- $ gpgv --status-fd 1 --keyring $k --weak-digest SHA1 file_*.dsc [GNUPG:] NEWSIG gpgv: Signature made Fri Apr 11 09:50:22 2025 CEST gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD gpgv: Note: signatures using the SHA1 algorithm are rejected gpgv: Note: third-party key signatures using the SHA1 algorithm are rejected gpgv: (use option "--allow-weak-key-signatures" to override) [GNUPG:] KEY_CONSIDERED 597308FBBDBA035D8C7C95DDC42C58EB591492FD 1 [GNUPG:] KEY_CONSIDERED 597308FBBDBA035D8C7C95DDC42C58EB591492FD 1 [GNUPG:] ERRSIG C42C58EB591492FD 1 10 01 1744357822 9 597308FBBDBA035D8C7C95DDC42C58EB591492FD [GNUPG:] NO_PUBKEY C42C58EB591492FD gpgv: Can't check signature: No public key $ echo $? 2 `--- > > 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. I think changing the default in GnuPG would be great, but my main interest as a developer of tools consuming SOPV is that it shows consistent behavior, which otherwise, as mentioned above, seems to be really confusing from a UI PoV, where the validation changes depending on the system and what implementations are installed and acting as the sopv entry point. (Where I guess the only way to get consistent results would be to use specific sopv implementations by their real name, and then choose ones that behave in a consistent way, which would not be ideal.) (I'm not cloning and reassigning, because I'm not sure whether these arguments are convincing, and to avoid a bug that would be wontfix'ed or closed. :) Thanks, Guillem
