[PATCH v3] test: add_gnupg_home should have ultimate trust on "its own" key

The typical use case for gpg is that if you control a secret key, you mark it with "ultimate" ownertrust. This bizarrely opaque --import-ownertrust mechanism is GnuPG's standard mechanism to set up ultimate ownertrust (the ":6" means "ultimate", for whatever reason). --- test/test-lib.sh | 1 +

[PATCH v2] test: add_gnupg_home should have ultimate trust on "its own" key

The typical use case for gpg is that if you control a secret key, you mark it with "ultimate" ownertrust. This bizarrely opaque --import-ownertrust mechanism is GnuPG's standard mechanism to set up ultimate ownertrust (the ":6" means "ultimate", for whatever reason). --- test/test-lib.sh | 1 +

Re: [PATCH] test: add_gnupg_home should have ultimate trust on "its own" key

On Wed 2019-04-24 18:06:44 -0400, Daniel Kahn Gillmor wrote: > The typical use case for gpg is that if you control a secret key, you > mark it with "ultimate" ownertrust. > > This bizarrely opaque --import-ownertrust mechanism is GnuPG's > standard mechanism to set up ultimate ownertrust (the ":6"

[PATCH] test: add_gnupg_home should have ultimate trust on "its own" key

The typical use case for gpg is that if you control a secret key, you mark it with "ultimate" ownertrust. This bizarrely opaque --import-ownertrust mechanism is GnuPG's standard mechanism to set up ultimate ownertrust (the ":6" means "ultimate", for whatever reason). --- test/test-lib.sh | 1 +

Easing access to the cryptographic envelope

E-mail structures are potentially arbitrarily complicated. Cryptographic protection standards like S/MIME and OpenPGP or PGP/MIME are often applicable to some elements of some messages. Last year's "E-Fail" attacks made it clear that trying to provide normal users with cryptographic protections

[PATCH 3/4] mime-node: track whole-message crypto state while walking the tree

Deliberately populate the message's cryptographic status while walking the MIME tree from the CLI. Note that the additional numchild argument added to _mime_node_create is a passthrough needed to be able to adequately populate the crypto state object. --- mime-node.c | 24

[PATCH 1/4] util/crypto: _notmuch_message_crypto: tracks message-wide crypto state

E-mail encryption and signatures reported by notmuch are at the MIME part level. This makes sense in the dirty details, but for users we need to have a per-message conception of the cryptographic state of the e-mail. (see https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html for more

[PATCH 4/4] cli/show: emit new whole-message crypto status output

This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing

[PATCH 2/4] cli: expose message-wide crypto status from mime-node

The mime node context (a per-message context) gains a cryptographic status object, and the mime_node_t object itself can return a view on that status to an interested party. The status is not yet populated, and for now we can keep that view read-only, so that it can only be populated/modified

Re: [PATCH] crypto: Avoid pretending to verify signatures on unsigned encrypted mail

On Sat 2019-04-20 13:02:57 -0400, Daniel Kahn Gillmor wrote: > Unsigned encrypted mail shows up with a weird empty signature list. > If we successfully decrypted and there was no signature in it, we > should just not show a sigstatus at all. Just a ping on this -- i don't think it should be

Re: [PATCH] tests: move FINGERPRINT definition to add_gnupg_home

Daniel Kahn Gillmor writes: > If a test has added a GnuPG homedir, it may well want to know the > fingerprint. This saves us from having to redefine this magic string > in multiple places when more tests evenutally use the GnuPG homedir. pushed, with typo in commit message fixed

Re: [PATCH] python: support relative path in default database

Doan Tran Cong Danh writes: > From notmuch 0.28, notmuch support relative database path in > notmuch-config(1), but python binding haven't taught this yet. > > afew denied to work with a perfectly fine notmuch-config due to this. pushed to master d

Re: [PATCH] emacs: Add missing type and group to defcustom variable

Örjan Ekeberg writes: > Added the type 'regexp and group 'notmuch-send as properties to the > customizable variable notmuch-mua-attachment-regexp. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org

Re: [PATCH 3/4] doc: use stamp file for html docs

Daniel Kahn Gillmor writes: >> >> -sphinx-texinfo: .texi.stamp >> +sphinx-texinfo: $(DOCBUILDDIR)/.texi.stamp > > I think this final change (to the sphinx-texinfo target) belongs in the > previous patchset. > > Otherwise, this series looks good to me, using your followup two-part > replacement

Re: [PATCH] emacs: hint that notmuch-mua-attachment-regexp is a regular expression

On Mon 2019-04-22 11:33:34 +0200, Örjan Ekeberg wrote: > This addresses the same issue, and therefore overlaps with the patch > I submitted a week ago. > (id:20190415133519.4532-1-ekeb...@kth.se) sorry, i'd missed your earlier patch! i agree that your patch is obviously better than mine, thanks