Russ Allbery wrote... > Christoph Biedl <debian.a...@manchmal.in-ulm.de> writes: > > > * Omitting the hash declaration is not an option either, perl-nocem > > fails then. > > I'm somewhat surprised by this, as my impression was that these Hash lines > are optional and GnuPG did the right thing if they were omitted entirely > (although you do still need a blank line).
That impression was on my side as well, and later the surprise. It would habe been a quick solution. It seems that pseudo-header is mandatory but I haven't checked further: https://sources.debian.org/src/gnupg2/2.2.40-1.1/g10/sig-check.c/?hl=188#L188 So, a blank line doesn't help. The message by gpgv is | gpgv: Signature made Fri Jan 5 18:21:01 2024 UTC | gpgv: using RSA key 87FB8F9D33883045A832B4FFD90D76CC97A7B20D | gpgv: WARNING: signature digest conflict in message | gpgv: Can't check signature: General error and this leads to an error message from perl-nocem: | Article <redacted>: unknown error (ID D90D76CC97A7B20D) where "WARNING: signature digest conflict in message" is the same as I had seen in the first place, when there was the hardcoded "SHA1". For completeness, this is gpgv 2.2.40-1.1, from Debian 12 ("bookworm"). Also, neither the NoCeM message nor the key are publicly available. > I have not looked into this in > detail, but I thought the hash algorithm was also present in metadata > inside the signature itself. It is indeed present there, I used pgpdump to reveal the hash algorithm is actually SHA512. So this is a design decision I don't quite follow, but possibly there is or was a need to do things that way. (...) > perl-nocem itself doesn't seem to care and just copies the whole input > into a temporary file for GnuPG. What's the nature of the failure? Is > GnuPG failing to validate the resulting file if the hash algorithm is > omitted? See above. Christoph
signature.asc
Description: PGP signature