Hi! 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 (made this severity serious due to this, but if you disagree, feel free to downgrade!). So, then doing something like: ,--- $ 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 `--- 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. :) Thanks, Guillem
severity -1 important # that's bad but doesn't really justify autoremoval thanks
Hi Guillem-- 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). 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 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,
control: severity -1 important # that's bad but doesn't really justify autoremoval thanks
Hi! 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? 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 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