T350 test failures with gnupg-2.1.16
Marius Bakke
mbakke at fastmail.com
Tue Nov 22 13:20:59 PST 2016
David Bremner <david at tethera.net> writes:
> Marius Bakke <mbakke at fastmail.com> writes:
>
>> David Bremner <david at tethera.net> writes:
>>
>>> Marius Bakke <mbakke at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20161122/4be298e1/attachment.sig>
More information about the notmuch
mailing list