Re: crypto test failures on Fedora and OpenSUSE
Hi Daniel,
Daniel Kahn Gillmor 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
signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: crypto test failures on Fedora and OpenSUSE
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)
We don't see this on Debian because gpgme in debian has carried this
patch for over a year now.
In gpgme 1.12.0 and earlier, this bug did not exist. But gpgme 1.13.0
introduced the bug in an attempt to avoid error diagnostics when *not*
trying to verify a signature while using a session key. The fix in
1.13.0 inadvertently introduced an error when the caller does actually
try to verify a signature, which is what we see here.
--dkg
From ae4d7761a15b82eb98b0bcc72af2ae2e8973e1f9 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Wed, 29 May 2019 17:56:01 -0400
Subject: [GPGME PATCH] gpg: Avoid error diagnostics with
--override-session-key when verifying
* src/engine-gpg.c (gpg_decrypt): only send --no-keyring when we are
not verifying.
--
Without this change, the signature verification would fail. This
problem was introduced in bded8ebc59c7fdad2617f4c9232a58047656834c in
an attempt to avoid an error when *not* verifying. Clearly more test
suite coverage is needed to avoid introducing this sort of problem in
the future.
GnuPG-bug-id: 3464
Signed-off-by: Daniel Kahn Gillmor
---
src/engine-gpg.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/engine-gpg.c b/src/engine-gpg.c
index 5c335cb2..223404ed 100644
--- a/src/engine-gpg.c
+++ b/src/engine-gpg.c
@@ -1717,12 +1717,15 @@ gpg_decrypt (void *engine,
strlen (override_session_key), 1);
if (!err)
{
- /* We add --no-keyring because a keyring is not required
- * when we are overriding the session key. It would
+ /* When we are not trying to verify signatures as well,
+ * we add --no-keyring because a keyring is not required
+ * for decryption when overriding the session key. It would
* work without that option but --no-keyring avoids that
* gpg return a failure due to a missing key log_error()
* diagnostic. --no-keyring is supported since 2.1.14. */
- err = add_arg (gpg, "--no-keyring");
+
+ if (!(flags & GPGME_DECRYPT_VERIFY))
+ err = add_arg (gpg, "--no-keyring");
if (!err)
err = add_arg (gpg, "--override-session-key-fd");
if (!err)
--
2.27.0
signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: crypto test failures on Fedora and OpenSUSE
David Bremner writes:
> I poked at this a bit more in gdb. I don't really know the code well,
> but it seems like whatever is happening is happening inside gmime. On
> the other hand both Fedora32 and my current Debian testing are running
> libgmime 3.2.7 and gpgme 1.13
>
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.
d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: crypto test failures on Fedora and OpenSUSE
I poked at this a bit more in gdb. I don't really know the code well,
but it seems like whatever is happening is happening inside gmime. On
the other hand both Fedora32 and my current Debian testing are running
libgmime 3.2.7 and gpgme 1.13
Looking at the sigstatus output, I think it is just a transcription of
what gmime returns.
"encstatus": [
{
"status": "good"
}
],
"sigstatus": [
{
"status": "error",
"keyid": "6D92612D94E46381",
"errors": {
"key-missing": true
}
}
],
I did notice that node->decrypt_success ends up being true, so it
suggests maybe bad reporting by gmime-on-fedora.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
crypto test failures on Fedora and OpenSUSE
Tomi Ollila writes:
> On Wed, Jun 17 2020, Tomi Ollila wrote:
>
>> On Wed, Jun 17 2020, Dan Čermák wrote:
>>
>>>
>>> I have tried updating the package in openSUSE Tumbleweed to 0.30~rc2 but
>>> running the tests results in the following failures:
>>> --8<---cut here---start->8---
>>> T357-index-decryption: Testing indexing decrypted mail
>>> FAIL verify signature with stashed session key
>>> good_sig: value not equal:
>>> data[0][0][0]["crypto"]["signed"]["status"][0]["status"] = 'error' != 'good'
>>
>> FYI: On Fedora 32 I (also) get:
>>
>> T357-index-decryption: Testing indexing decrypted mail
>>FAIL verify signature with stashed session key
>> good_sig: value not equal:
>> data[0][0][0]["crypto"]["signed"]["status"][0]["status"] = 'error' != 'good'
>>
>> (i.e exactly the same)
>>
>> I've not bothered to care ;/
>
> However, more detail:
>
> executed
>
> notmuch show --format=json id:encrypted-sig...@crypto.notmuchmail.org | jq .
>
> before that failing test -- this is the related data:
>
> "crypto": {
> "signed": {
> "status": [
> {
> "status": "error",
> "keyid": "6D92612D94E46381",
> "errors": {
> "key-missing": true
> }
> }
> ],
> "encrypted": true
> },
>
I thought maybe the problem was missing GNUPGHOME setting when you ran
that by hand, but it seems not:
[bremner@Fedora-Cloud-Base-32-1 tmp.T357-index-decryption]$ gpg --homedir
/tmp/notmuch-test-51641.23MdYj/gnupg/ -k
gpg: Warning: using insecure memory!
/tmp/notmuch-test-51641.23MdYj/gnupg/pubring.kbx
pub rsa1024 2011-02-05 [SC]
5AEAB11F5E33DCE875DDB75B6D92612D94E46381
uid [ultimate] Notmuch Test Suite
(INSECURE!)
sub rsa1024 2011-02-05 [E]
[bremner@Fedora-Cloud-Base-32-1 tmp.T357-index-decryption]$
GNUPGHOME=/tmp/notmuch-test-51641.23MdYj/gnupg ../../notmuch
--config=./notmuch-config show --format=json
id:encrypted-sig...@crypto.notmuchmail.org
[[[{"id": "encrypted-sig...@crypto.notmuchmail.org", "match": true, "excluded":
false, "filename":
["/home/bremner/notmuch-0.30~rc2/test/tmp.T357-index-decryption/mail/encrypted-signed.eml"],
"timestamp": 1559124562, "date_relative": "2019-05-29", "tags": ["encrypted",
"inbox", "unread"], "body": [{"id": 1, "encstatus": [{"status": "good"}],
"sigstatus": [{"status": "error", "keyid": "6D92612D94E46381", "errors":
{"key-missing": true}}], "content-type": "multipart/encrypted", "content":
[{"id": 2, "content-type": "application/pgp-encrypted", "content-length": 11},
{"id": 3, "content-type": "text/plain", "content": "My father was the keeper of
the Eddystone Light\nSlept with a mermaid one fine night\nAnd of this union
there came three\nA porgy and a porpoise and the third was me\n\nYo ho ho, the
wind blows free\nO for a life on the rolling sea!\n"}]}], "crypto": {"signed":
{"status": [{"status": "error", "keyid": "6D92612D94E46381", "errors":
{"key-missing": true}}], "encrypted": true}, "decrypted": {"status": "full"}},
"headers": {"Subject": "Lyrics", "From": "test_su...@notmuchmail.org", "To":
"test_su...@notmuchmail.org", "Date": "Wed, 29 May 2019 06:09:22 -0400"}}, [
No jq in this container, but you can search for the same error string.
In case it's relevant, I have gmime30-devel version 3.2.7-1.fc32 and
gnupg 2.2.19-1.fc32
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
