[BUG] gmime-3.0.1 (was: [PATCH] crypto: gracefully handle gmime errors)

Jan Malakhovski oxij at oxij.org
Tue Sep 5 05:55:06 PDT 2017


Hi.

David Bremner <david at tethera.net> writes:

> I'm fairly certain this something nix specific. 3.0.1 is the
> default version of gmime I develop against these days.
>
>> patching sources
>
> What patches, if any are applied here?

None.

>> T350-crypto: Testing PGP/MIME signature verification and decryption
>>  PASS   emacs delivery of signed message
>>  FAIL   signature verification
>> 	--- T350-crypto.2.expected	2017-08-31 14:25:03.126885225 +0000
>> 	+++ T350-crypto.2.output	2017-08-31 14:25:03.126885225 +0000
>> 	@@ -18,13 +18,7 @@
>> 	                         ], 
>> 	                         "content-type": "multipart/signed", 
>> 	                         "id": 1, 
>> 	-                        "sigstatus": [
>> 	-                            {
>> 	-                                "created": 946728000, 
>> 	-                                "fingerprint": "5AEAB11F5E33DCE875DDB75B6D92612D94E46381", 
>> 	-                                "status": "good"
>> 	-                            }
>> 	-                        ]
>> 	+                        "sigstatus": []
>> 	                     }
>> 	                 ], 
>> 	                 "date_relative": "2000-01-01", 
>> Failed to verify signed part: Cannot verify multipart/signed part: unregistered signature protocol 'application/pgp-signature'.
>
> It seems like your gmime install doesn't understand PGP/MIME. That's
> pretty strange since afaik it enables SMIME and PGP/MIME with the same flag.
>
> Previously you wrote
> ,----
> |    I wonder why gnupg stops getting referenced with gmime-3.0.1. My guess
> |    is that `./configure` does something very different when compiling with
> |    gmime-3.
> `----
>
> Although I don't think that configure is really the problem, the missing
> dependence on gnupg is suspicious.  Not having a gpg binary at all
> should cause more failures and/or messages about skipping. It's hard for
> me to test because on Debian there is a hard dependency of gmime-3.0 on
> gnupg.

I added `gpgme` to `buildInputs` of `gmime` and now `notmuch` passes all
the tests. Yay! So that was the root problem.

Is it correct to assume that when building with `gmime-3` `notmuch`
stops calling `gpg` binary and does all the things PGP using `gmime-3`?

It's the only explanation I have for why `notmuch` package stops
directly referencing `gpg` even when the sources get patched with
's/gpg/${pkgs.gpg}/bin/gpg/g' (not exactly, but close enough).

Cheers,
  Jan


More information about the notmuch mailing list