Feature freeze for notmuch 0.30: June 1

Feature freeze for notmuch 0.30: June 1

[David Bremner]

[-- Attachment #1.1: Type: text/plain, Size: 252 bytes --]


I plan to tag the first release candidate for notmuch 0.30 on June
1. It's long past time we had a release, and the new python bindings in
particular need a wider audience.  Per usual, I'll accept (some) bug
fixes and NEWS updates after that date.

d

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Feature freeze for notmuch 0.30: June 1

[David Bremner]

[-- Attachment #1.1: Type: text/plain, Size: 598 bytes --]

David Bremner <david@tethera.net> writes:

> I plan to tag the first release candidate for notmuch 0.30 on June
> 1. It's long past time we had a release, and the new python bindings in
> particular need a wider audience.  Per usual, I'll accept (some) bug
> fixes and NEWS updates after that date.
>

As promised, I tagged the first release candidate, and we are in feature
freeze. I do want to get at least the one known memory management bug
for the notmuch2 python module fixed before release. There's a patch in
progress.

Debian users can try the release candidate in debian experimental.

d

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Feature freeze for notmuch 0.30: June 1

[David Bremner]

[-- Attachment #1.1: Type: text/plain, Size: 399 bytes --]


I've tagged a 3rd release candidate (which is of course rc2, because
this week I belong to the cult of 0 based indexing). All of the blockers
I know of are fixed, and I'd consider us in "deep freeze", hopefully to
release in a week or so if there are no nasty bugs discovered.

Please test.  Debian users can grab it from Debian experimental (really
this time, previously it had to go though NEW).

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Feature freeze for notmuch 0.30: June 1

[Dan Čermák]

David Bremner <david@tethera.net> writes:

> I've tagged a 3rd release candidate (which is of course rc2, because
> this week I belong to the cult of 0 based indexing). All of the blockers
> I know of are fixed, and I'd consider us in "deep freeze", hopefully to
> release in a week or so if there are no nasty bugs discovered.
>
> Please test.  Debian users can grab it from Debian experimental (really
> this time, previously it had to go though NEW).

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'

T590-thread-breakage: Testing thread breakage during reindexing
 BROKEN No ghosts should remain after deletion of second message

T670-duplicate-mid: Testing duplicate message ids
 BROKEN First subject preserved in notmuch-show (json)
 BROKEN Regexp search for second subject

Notmuch test suite complete.
1152/1156 tests passed.
3 broken tests failed as expected.
1 test failed.
All tests in 1 file skipped.
ERROR: parallel test suite returned error code 1
make: *** [test/Makefile.local:69: test] Error 1
--8<---------------cut here---------------end--------------->8---

I can reproduce these failures on my local machine as well as in the
openSUSE build environment (the Open Build Service). As I am a bit
reluctant to skip even more tests: could someone who is more familiar
with notmuch maybe take a look at this or guide me through this?


Thanks in advance,

Dan

Re: Feature freeze for notmuch 0.30: June 1

[Tomi Ollila]

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 ;/

The BROKEN failures are expected failures...

Tomi


>
> T590-thread-breakage: Testing thread breakage during reindexing
>  BROKEN No ghosts should remain after deletion of second message
>
> T670-duplicate-mid: Testing duplicate message ids
>  BROKEN First subject preserved in notmuch-show (json)
>  BROKEN Regexp search for second subject
>
> Notmuch test suite complete.
> 1152/1156 tests passed.
> 3 broken tests failed as expected.
> 1 test failed.
> All tests in 1 file skipped.
> ERROR: parallel test suite returned error code 1
> make: *** [test/Makefile.local:69: test] Error 1
> --8<---------------cut here---------------end--------------->8---
>
> I can reproduce these failures on my local machine as well as in the
> openSUSE build environment (the Open Build Service). As I am a bit
> reluctant to skip even more tests: could someone who is more familiar
> with notmuch maybe take a look at this or guide me through this?
>
>
> Thanks in advance,
>
> Dan

Re: Feature freeze for notmuch 0.30: June 1

[Tomi Ollila]

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-signed@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
          },

>
> The BROKEN failures are expected failures...
>
> Tomi
>

crypto test failures on Fedora and OpenSUSE

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> 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-signed@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 <test_suite@notmuchmail.org> (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-signed@crypto.notmuchmail.org
[[[{"id": "encrypted-signed@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_suite@notmuchmail.org", "To": "test_suite@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

Re: crypto test failures on Fedora and OpenSUSE

[David Bremner]

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.

Re: crypto test failures on Fedora and OpenSUSE

[David Bremner]

David Bremner <david@tethera.net> 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

Re: crypto test failures on Fedora and OpenSUSE

[Daniel Kahn Gillmor]

[-- Attachment #1.1.1: Type: text/plain, Size: 1802 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: 0001-gpg-Avoid-error-diagnostics-with-override-session-ke.patch --]
[-- Type: text/x-diff, Size: 2006 bytes --]

From ae4d7761a15b82eb98b0bcc72af2ae2e8973e1f9 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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 <dkg@fifthhorseman.net>
---
 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


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Re: crypto test failures on Fedora and OpenSUSE

[Dan Čermák]

[-- Attachment #1.1: Type: text/plain, Size: 1674 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

[PATCH 1/2] configure: can gpgme can verify signatures when decrypting with a session key?

[Daniel Kahn Gillmor]

If https://dev.gnupg.org/T3464 is unresolved in the version of gpgme
we are testing against, then we should know about it, because it
affects the behavior of notmuch.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
---
 configure | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 77 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 2e01034b..2caa08c8 100755
--- a/configure
+++ b/configure
@@ -620,6 +620,78 @@ EOF
     if [ -n "$TEMP_GPG" -a -d "$TEMP_GPG" ]; then
         rm -rf "$TEMP_GPG"
     fi
+
+    # see https://dev.gnupg.org/T3464
+    # there are problems verifying signatures when decrypting with session keys with GPGME 1.13.0 and 1.13.1
+    printf "Checking signature verification when decrypting using session keys... "
+
+    cat > _verify_sig_with_session_key.c <<EOF
+#include <stdio.h>
+#include <gmime/gmime.h>
+
+int main () {
+    GError *error = NULL;
+    GMimeParser *parser = NULL;
+    GMimeMultipartEncrypted *body = NULL;
+    GMimeDecryptResult *result = NULL;
+    GMimeSignatureList *sig_list = NULL;
+    GMimeSignature *sig = NULL;
+    GMimeObject *output = NULL;
+    GMimeSignatureStatus status;
+    int len;
+
+    g_mime_init ();
+    parser = g_mime_parser_new ();
+    g_mime_parser_init_with_stream (parser, g_mime_stream_file_open("$srcdir/test/corpora/crypto/encrypted-signed.eml", "r", &error));
+    if (error) return !! fprintf (stderr, "failed to instantiate parser with test/corpora/pkcs7/smime-onepart-signed.eml\n");
+
+    body = GMIME_MULTIPART_ENCRYPTED(g_mime_message_get_mime_part (g_mime_parser_construct_message (parser, NULL)));
+    if (body == NULL) return !!	fprintf (stderr, "did not find a multipart/encrypted message\n");
+
+    output = g_mime_multipart_encrypted_decrypt (body, GMIME_DECRYPT_NONE, "9:13607E4217515A70EC8DF9DBC16C5327B94577561D98AD1246FA8756659C7899", &result, &error);
+    if (error || output == NULL) return !! fprintf (stderr, "decrypt failed\n");
+
+    sig_list = g_mime_decrypt_result_get_signatures (result);
+    if (sig_list == NULL) return !! fprintf (stderr, "sig_list is NULL\n");
+
+    if (sig_list == NULL) return !! fprintf (stderr, "no GMimeSignatureList found\n");
+    len = g_mime_signature_list_length (sig_list);
+    if (len != 1) return !! fprintf (stderr, "expected 1 signature, got %d\n", len);
+    sig = g_mime_signature_list_get_signature (sig_list, 0);
+    if (sig == NULL) return !! fprintf (stderr, "no GMimeSignature found at position 0\n");
+    status = g_mime_signature_get_status (sig);
+    if (status & GMIME_SIGNATURE_STATUS_KEY_MISSING) return !! fprintf (stderr, "signature status contains KEY_MISSING (see https://dev.gnupg.org/T3464)\n");
+
+    return 0;
+}
+EOF
+    if ! TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XXXXXX"); then
+        printf 'No.\nCould not make tempdir for testing signature verification when decrypting with session keys.\n'
+        errors=$((errors + 1))
+    elif ${CC} ${CFLAGS} ${gmime_cflags} _verify_sig_with_session_key.c ${gmime_ldflags} -o _verify_sig_with_session_key \
+            && GNUPGHOME=${TEMP_GPG} gpg --batch --quiet --import < "$srcdir"/test/gnupg-secret-key.asc \
+            && rm -f ${TEMP_GPG}/private-keys-v1.d/*.key
+    then
+        if GNUPGHOME=${TEMP_GPG} ./_verify_sig_with_session_key; then
+            gmime_verify_with_session_key=1
+            printf "Yes.\n"
+        else
+            gmime_verify_with_session_key=0
+            printf "No.\n"
+            cat <<EOF
+*** Error: GMime fails to verify signatures when decrypting with a session key.
+
+This is most likely due to a buggy version of GPGME, which should be fixed in 1.13.2 or later.
+See https://dev.gnupg.org/T3464 for more details.
+EOF
+        fi
+    else
+        printf 'No.\nFailed to set up gpg for testing signature verification while decrypting with a session key.\n'
+        errors=$((errors + 1))
+    fi
+    if [ -n "$TEMP_GPG" -a -d "$TEMP_GPG" ]; then
+        rm -rf "$TEMP_GPG"
+    fi
 else
     have_gmime=0
     printf "No.\n"
@@ -1144,7 +1216,8 @@ for flag in -Wmissing-declarations; do
 done
 printf "\n\t%s\n" "${WARN_CFLAGS}"
 
-rm -f minimal minimal.c _time_t.c _libversion.c _libversion _libversion.sh _check_session_keys.c _check_session_keys _check_x509_validity.c _check_x509_validity
+rm -f minimal minimal.c _time_t.c _libversion.c _libversion _libversion.sh _check_session_keys.c _check_session_keys _check_x509_validity.c _check_x509_validity \
+   _verify_sig_with_session_key.c _verify_sig_with_session_key
 
 # construct the Makefile.config
 cat > Makefile.config <<EOF
@@ -1438,6 +1511,9 @@ NOTMUCH_DEFAULT_XAPIAN_BACKEND=${default_xapian_backend}
 # Whether GMime can verify X.509 certificate validity
 NOTMUCH_GMIME_X509_CERT_VALIDITY=${gmime_x509_cert_validity}
 
+# Whether GMime can verify signatures when decrypting with a session key:
+NOTMUCH_GMIME_VERIFY_WITH_SESSION_KEY=${gmime_verify_with_session_key}
+
 # do we have man pages?
 NOTMUCH_HAVE_MAN=$((have_sphinx))
 
-- 
2.27.0
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

[PATCH 2/2] tests: mark sig verification known-broken with session keys on buggy gpgme

[Daniel Kahn Gillmor]

We make use of the just-introduced configure test.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
---
 test/T357-index-decryption.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/test/T357-index-decryption.sh b/test/T357-index-decryption.sh
index 1ac2836a..1ed5f28c 100755
--- a/test/T357-index-decryption.sh
+++ b/test/T357-index-decryption.sh
@@ -306,6 +306,9 @@ test_json_nodes <<<"$output" "$goodsig"
 
 test_begin_subtest "verify signature with stashed session key"
 output=$(notmuch show --format=json id:encrypted-signed@crypto.notmuchmail.org)
+if [ $NOTMUCH_GMIME_VERIFY_WITH_SESSION_KEY -ne 1 ]; then
+    test_subtest_known_broken
+fi
 test_json_nodes <<<"$output" "$goodsig"
 
 # TODO: test removal of a message from the message store between
-- 
2.27.0
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Re: [PATCH 1/2] configure: can gpgme can verify signatures when decrypting with a session key?

[David Bremner]

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

> If https://dev.gnupg.org/T3464 is unresolved in the version of gpgme
> we are testing against, then we should know about it, because it
> affects the behavior of notmuch.

The series seems to work fine. One thing I noticed on Fedora 32 (in a
systemd-nspawn session) is many warnings from gpg about using insecure
memory which make the output a bit hard to read. I'm not sure if that's
something we'd want to hide, or it's particular to this container setup.

d
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Re: [PATCH 1/2] configure: can gpgme can verify signatures when decrypting with a session key?

[David Bremner]

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

> If https://dev.gnupg.org/T3464 is unresolved in the version of gpgme
> we are testing against, then we should know about it, because it
> affects the behavior of notmuch.
>

series is applied as part of 0.30~rc3

d
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Re: Feature freeze for notmuch 0.30: June 1

[David Bremner]

[-- Attachment #1.1: Type: text/plain, Size: 737 bytes --]

David Bremner <david@tethera.net> writes:

> I've tagged a 3rd release candidate (which is of course rc2, because
> this week I belong to the cult of 0 based indexing). All of the blockers
> I know of are fixed, and I'd consider us in "deep freeze", hopefully to
> release in a week or so if there are no nasty bugs discovered.

I've tagged a fourth release candidate 0.30~rc3, uploaded to notmuchmail.org and
Debian experimental.

The main issue I'm aware of is a rumoured file descriptor with the new
python bindings. I can't hold the release indefinitely for this. If
someone can produce a small standalone reproducer and send it to the
list now, I'll have a look at it. Otherwise the problem will have to
wait for a bug fix release.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org