Re: revisiting Autocrypt in notmuch, MVP
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"))) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
Steven Allen 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. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
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/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
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 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: revisiting Autocrypt in notmuch, MVP
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 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
revisiting Autocrypt in notmuch, MVP
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 signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
