Hi Daniel,

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> Hi folks--
>
> On Sun 2020-06-28 08:33:42 -0300, David Bremner wrote:
>> I dug a bit further down, and this is what is returned from gpgme
>> (line 345 in g_mime_gpgme_get_signatures)
>>
>> sig = {next = 0x0,
>>     summary = GPGME_SIGSUM_KEY_MISSING, 
>>     fpr = 0x4ac480 "5AEAB11F5E33DCE875DDB75B6D92612D94E46381", status = 9, 
>>     notations = 0x0, timestamp = 1559167762, exp_timestamp = 0, wrong_key_usage = 0, 
>>     pka_trust = 0, chain_model = 0, is_de_vs = 0, _unused = 0, 
>>     validity = GPGME_VALIDITY_UNKNOWN, validity_reason = 0, 
>>     pubkey_algo = GPGME_PK_RSA, hash_algo = GPGME_MD_SHA256, pka_address = 0x0, 
>>     key = 0x0}
>>
>> At this point I'm leaning towards declaring it a gpgme problem in
>> fedora32, and suggesting that relevant distros mark the test broken. I
>> am of course open to more informed opinions.
>
> The problem does indeed appear to be with gpgme, in versions 1.13.0 and
> 1.13.1.
>
> In particular, it is a problem with the resolution of
> https://dev.gnupg.org/T3464, which is ultimately fixed upstream, but is
> not yet fixed in a released version of gpgme.
>
> The upstream commit, which should be patched into gpgme on Fedora and
> OpenSUSE (and anywhere else that depends on gpgme) is:
>
>     https://dev.gnupg.org/rMae4d7761a15b82eb98b0bcc72af2ae2e8973e1f9
>
> (patch attached here as well)

Thank you for digging into this and finding the underlying issue (I
would have never been able to find it)!
I have submitted the patch to openSUSE and it will hopefully be included
there soon.


Cheers,

Dan