revisiting Autocrypt in notmuch, MVP

revisiting Autocrypt in notmuch, MVP

[Antoine Beaupré]

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

Hi!

I'm giving an OpenPGP training this week, which I haven't done in
ages. A lot has changed since then: keyservers are basically dead (or
have changed significantly), WKD and Autocrypt exist and are supported
out of the box by Thunderbird, which simplifies a lot of things.

While testing out Thunderbird, I realized I wasn't sending out autocrypt
headers. I find those headers really precious, as they allow me to TOFU
users when they send me encrypted email. I have a rough hack to parse
incoming email and manually importing them in my keyring:

https://gitlab.com/anarcat/scripts/-/blob/dd898332c4e6c829fd18455fe3f1bbbee37e9551/autocrypt-key-import

That used to be a complicated Python program, but it turns out that
sequoia directly supports parsing those headers! So it's now this
one-liner:

    sq autocrypt decode | gpg --import

So I have a basic MVP (minimal viable product) for importing keys. But
what about *sending* keys, i.e. embedding keys in outgoing messages?

Well, this (and parsing incoming keys too, obviously) is something that
was discussed before:

https://nmbug.notmuchmail.org/nmweb/show/20210221152132.2302112-1-dme%40dme.org

That discussion somewhat died out as dkg suggested to fix the problem
more broadly, and things stalled there.

And while autocrypt has a nice beautiful and brilliant spec that does
everything, that's not what I'm looking at right now. And I don't think
it's productive to block in this way at this point.

So I made a bespoke implementation that just calls out to sequoia (and
yes, also gpg, hopefully one day the latter can just go away) to insert
autocrypt headers to outgoing mail. Here's the implementation:

https://gitlab.com/anarcat/emacs-d/-/blob/354fabad24100f69310dd16a0d30ac3bd96d7244/notmuch-config.el#L14-31

It's brittle, but it works for my case.

I don't think this is something that can be merged as-is in notmuch. It
depends on gnupg and sequoia, and it's probably incorrect as far as the
Autocrypt spec is concerned (in particular it doesn't use a UID to
fingerprint map), but this all seems like things could be improved.

So that's what I got. I hope that helps! :)

a.

-- 
Celui qui ne connaît pas l'histoire est condamné à la revivre.
                        - Karl Marx

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

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

Re: revisiting Autocrypt in notmuch, MVP

[Antoine Beaupré]

On 2023-04-26 12:10:09, Antoine Beaupré wrote:
[...]

> And while autocrypt has a nice beautiful and brilliant spec that does
> everything, that's not what I'm looking at right now. And I don't think
> it's productive to block in this way at this point.
>
> So I made a bespoke implementation that just calls out to sequoia (and
> yes, also gpg, hopefully one day the latter can just go away) to insert
> autocrypt headers to outgoing mail. Here's the implementation:
>
> https://gitlab.com/anarcat/emacs-d/-/blob/354fabad24100f69310dd16a0d30ac3bd96d7244/notmuch-config.el#L14-31
>
> It's brittle, but it works for my case.
>
> I don't think this is something that can be merged as-is in notmuch. It
> depends on gnupg and sequoia, and it's probably incorrect as far as the
> Autocrypt spec is concerned (in particular it doesn't use a UID to
> fingerprint map), but this all seems like things could be improved.

A small update on this: I just realized I was sending autocrypt headers
regardless of whether or not I was signing / encrypting mails. I'm not
sure this is a good idea. The spec says that I "SHOULD", I believe:

https://autocrypt.org/level1.html#header-injection-in-outbound-mail

... but it feels a bit too intrusive... Do I really want to divulge my
cryptographic identity to the world constantly? I'm using ed25519 keys
now, so the header is small, but for other users, that grows the message
size significantly...

Patch is:

https://gitlab.com/anarcat/emacs-d/-/commit/c79495f8580735c23748a62db99b3d9f34f413f5

Interestingly, i had to make a new mml-* function; there's a predicate
to check if a message is encrypted, but not if it's signed, which seems
silly. So I vendored and improved the code, which also feels silly.

So there you go, diverging from the standard already. :)

A.

-- 
You Are What You Is
                        - Frank Zappa\r

Re: revisiting Autocrypt in notmuch, MVP

[Antoine Beaupré]

On 2024-02-22 22:22:13, Antoine Beaupré wrote:
> On 2023-04-26 12:10:09, Antoine Beaupré wrote:

[...]

> ... but it feels a bit too intrusive... Do I really want to divulge my
> cryptographic identity to the world constantly? I'm using ed25519 keys
> now, so the header is small, but for other users, that grows the message
> size significantly...

After talking with dkg on IRC, I realized my concerns were overblown:
autocrypt actually strips out the other identities, so i'm not divulging
more than already present in the mail (apart from the public key
material itself of course).

So I've reverted this.

-- 
One of the things the Web teaches us is that everything is connected
(hyperlinks) and we all should work together (standards). Too often
school teaches us that everything is separate (many different
'subjects') and that we should all work alone.  - Aaron Swartz\r

Re: revisiting Autocrypt in notmuch, MVP

[Steven Allen]

There's actually a pretty decent autocrypt package[1] for Emacs, only
lacking notmuch integration. But writing that based on the mu4e
integration should be pretty trivial.

[1]: https://git.sr.ht/~pkal/autocrypt/

Re: revisiting Autocrypt in notmuch, MVP

[Sandra Snan]

Steven Allen <steven@stebalien.com> writes:

> There's actually a pretty decent autocrypt package[1] for Emacs, 
> only lacking notmuch integration. But writing that based on the 
> mu4e integration should be pretty trivial. 
> 
> [1]: https://git.sr.ht/~pkal/autocrypt/ 

I've been working on that actually so check out that project's 
mailing lists for the patches I've been sending. I've been seeing 
some weird behavior when testing and I wanna iron out all the 
kinks before we merge it, but patches-to-my-patches in that regard 
are more than welcome.♥︎

There are some huge differences between notmuch and mu4e with 
regards to the timing of message access and hooks. Please check 
the commit history of my patches on pkal's mailing list, or get my 
dev repo at

git clone https://idiomdrottning.org/autocrypt

I think my code here is solid and my remaining issues (I've been 
seeing incompabilities with Delta Chat) are with the autocrypt 
library and not with my interface code, but, more eyes would be 
good.

Note that since autocrypt aspires to become an ELPA project you need FSF
assignment forms to work on it.\r

Re: revisiting Autocrypt in notmuch, MVP

[Steven Allen]

Awesome, and I see you're already upstreaming hooks. But I think you can
simplify this because every reply buffer has a hidden "In-Reply-To"
header (can be shown with `message-widen-and-recenter`). You should be
able to attach a hook to `message-setup-hook`, I think? Ideally you'd
use `message-header-hook`, but that doesn't appear to be run by notmuch.

So, something like should get you the ID of the message to which we're replying.

    (save-restriction
      (message-narrow-to-headers)
      (mail-header-parse-address-lax (mail-fetch-field "In-Reply-To")))