David Bremner <david@tethera.net> writes: > Marius Bakke <mbakke@fastmail.com> writes: > >> David Bremner <david@tethera.net> writes: >> >>> Marius Bakke <mbakke@fastmail.com> writes: >>> >>>> Hello! >>>> >>>> After updating to gnupg 2.1.16, T350-crypto.sh fails in some of the >>>> signature verification steps with wrong content-length: >>>> >>>> T350-crypto: Testing PGP/MIME signature verification and decryption >>>> PASS emacs delivery of signed message >>>> FAIL signature verification >>>> --- T350-crypto.2.expected 2016-11-22 18:59:48.341851653 +0000 >>>> +++ T350-crypto.2.output 2016-11-22 18:59:48.341851653 +0000 >>>> @@ -11,7 +11,7 @@ >>>> "id": 2 >>>> }, >>>> { >>>> - "content-length": 280, >>>> + "content-length": 312, >>>> "content-type": "application/pgp-signature", >>> >>> These failures are not duplicated for me in debian sid, also with gpg >>> 2.1.16. From IRC I believe Marius is running GuixSD. >> >> This is correct. Strange that it's not reproducible on Debian. Any tips >> for how to troubleshoot this further? Is the content-length based on >> signature only? I'll see if I can extract the raw output somehow. > > You could start with the following, from inside tmp.T350-crypto > > % grep -R "Subject: test signed message 001" mail > % ../../devel/printmimestructure < mail/sent/cur/$the_file_matched_by_grep > > That will tell us if the mismatch is in the created file or in the later > parsing. Thanks for this! It seems the signature is 32 bytes longer in 2.1.16. ../../devel/printmimestructure < mail/sent/cur/1479841188.2873_194073_1.localhost\:2\,S └┬╴multipart/signed 778 bytes ├─╴text/plain 31 bytes └─╴application/pgp-signature [signature.asc] 312 bytes vs... ../../devel/printmimestructure < mail/sent/cur/1479848474.6836_793177_1.localhost\:2\,S └┬╴multipart/signed 747 bytes ├─╴text/plain 31 bytes └─╴application/pgp-signature [signature.asc] 280 bytes The signatures of each email: 2.1.16: --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iLMEAQEIAB0WIQRa6rEfXjPc6HXdt1ttkmEtlORjgQUCWDSVpAAKCRBtkmEtlORj gf90A/4twA6txofm53BhqVAOUwdQNmA2H/yDhP29k6ctZ+XeTw77VZgrFMERoll7 lG6MEsH4JiMasJoevOohRsNmA9F3cEy5b38+c5KuaUlz5jVAKLZ4e8jkZmw2t8L+ hDbtLt7vzd72as8i9yNfKhf1DqAU9ayCJgXOMN4ql/uZqbWIqQ== =o1L0 -----END PGP SIGNATURE----- --=-=-=-- 2.1.15: --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJwEAQEIAAYFAlg0shoACgkQbZJhLZTkY4H4ewQAoWTNwOtQAH/fwlgkqBuWLoWB 7CrrW3Lj1vEVaTRkaBIFP7NiYTDGZtWP6KCZ7G9HXsyprsg5HtVIp3wl4DHKmK/u XipG0l3PNkSv9+SuUVxI4E9dj0kTJzNLqZaRYf3kmQJTs/jTyxQCuqPd1JF5kD9e Nkd1585nFCNQAdNJgIE= =8npB -----END PGP SIGNATURE----- --=-=-=-- Reading through the ChangeLog, I can't see anything obviously related. One workaround could be setting an explicit key algorithm instead of relying on the default. I'll have a go at this.