Hi Bremner, thanks for flagging this.

On Fri 2022-03-18 07:48:01 -0300, David Bremner wrote:
> One of the SMIME tests is failing for me.
>
> T355-smime: Testing S/MIME signature verification and decryption
>  FAIL   signature verification (notmuch CLI)
> 	--- T355-smime.4.expected	2022-03-18 10:31:31.877258855 +0000
> 	+++ T355-smime.4.output	2022-03-18 10:31:31.877258855 +0000
> 	@@ -24,7 +24,7 @@
> 	                         "sigstatus": [
> 	                             {
> 	                                 "created": 946728000,
> 	-                                "email": "<test_suite@notmuchmail.org>",
> 	+                                "email": "test_suite@notmuchmail.org",
> 	                                 "expires": 424242424,
> 	                                 "fingerprint": "616F46CD73834C63847756AF0DFB64A6E0972A47",
> 	                                 "status": "good",
> 	@@ -38,7 +38,7 @@
> 	                         "status": [
> 	                             {
> 	                                 "created": 946728000,
> 	-                                "email": "<test_suite@notmuchmail.org>",
> 	+                                "email": "test_suite@notmuchmail.org",
> 	                                 "expires": 424242424,
> 	                                 "fingerprint": "616F46CD73834C63847756AF0DFB64A6E0972A47",
> 	                                 "status": "good",
>
>
> I'm running gpgsm 2.2.27, gpgme 1.16.0, and gmime 3.2.9. At guess the
> change is due to the recent gmime upgrade, but that is pure speculation,
> I could not find anything in the gmime git log to back it up.

I think it is probably due to this squashed changeset in gmime:
https://github.com/jstedfast/gmime/commit/0ab298a0086c09c403b5d35effa73b59f271693d

(yes, this is my own proposed change, weirdly re-structured by github)

The root motivation for this change is some lack of clarity in the
underlying gpgme toolkit, which i've never been able to get resolved:
https://dev.gnupg.org/T5450

> The change looks innocuous enough, but of course it's enough to break
> the test, and I'm not sure how to make this consistent between
> versions.

I suppose the right way to fix this generically is a test which
abstracts out whether gmime reports an angle-addr or a addr-spec for
x.509 certs, and then adjust the tests to match.

I can try to send a patch for this, but it'll take me a while to swap
it all back in.

If anyone wants to propose a patch in the meantime, i'd also be happy to
review.

The simplest thing in the short term is probably to switch the test to
matching based on the bare e-mail address and assert a build-dep on
gmime 3.2.8 (see attached), but that seems a little bit extreme, since
gmime only released 3.2.9 recently (and 3.2.8 never made it out the door
via any formal channels, if i understand the history correctly).

I'll see whether i can make a better fix.

   --dkg