Hi Frank-- On Fri 2025-11-07 15:02:36 +0000, Frank Seifferth wrote: > My script is very similar in spirit to the MVP proposed by Antoine > Beaupré in April 2023, yet it offers a slightly different UI. One of my > main design decisions was *not* to introduce the idea of an accounts and > a peers table into notmuch. Instead, I simply treat the email database > as if it were a local key server that can be queried to import keys into > the gpg keyring by running, e.g., > > notmuch autocrypt --locate-keys [email protected]
this is super interesting, thanks for publishing it! I'm many many years behind of buckling down and getting the thing i wanted to get done for notmuch and autocrypt, so i really appreciate your stepping up and offering something concrete. The accounts and peers table in the autocrypt spec describe one way to get to the deterministic query of "what OpenPGP certificate should I use for this peer?" even in the situation where messages arrive out of order, are deleted, etc. And if a certificate is available for the peer in question, it also yields a recommendation for "shen composing a new message to this peer, should the new message be encrypted by default?" Do you think your script's implementation would yield the same result for these queries, even without maintaining a table? That would be a very nice result. > This UI deliberately mirrors gpg, where you can run `gpg --locate-keys` to > retrieve keys from a WKD. I found it very natural to model the autocrypt > key import functionality as a query against the email database, and I > believe that this approach might be more promising than sticking too > closely to the UI described in the autocrypt spec. I'm a long-time user of (and contributor to) GnuPG but i gotta say i would *not* try to deliberately mirror the UI of gpg. it's kind of a mess. I've found notmuch's interface to be better organized -- it seems like it might be better to try to extend notmuch's interface to map to the queries supported by autocrypt, and then backfill from that to figure out whether we need to change the database at any infrastructural level. This script also seems devoted to working with gpg. I know that notmuch is pretty dependent (through gmime) on gpg at the moment, but there are many other OpenPGP compatible tools available today -- it'd be cool if this tooling just extracted the Autocrypt recommendation (certificate plus default choice of encrypted), and the user could plug the relevant certificate and policy information into their own OpenPGP tooling. > Until now, `notmuch-autocrypt` is still limited to my own very specific > use case[3]. However, I believe that it could be a promising starting > point for finally bringing autocrypt support to notmuch. So if anyone > reading this mailing list should be interested in pursuing the MVP > approach a little further, I would be very happy to hear from you. I think this is a great starting point. I love the simplicity of it, but i also think the simplicity might be a bit risky (e.g. https://github.com/seifferth/notmuch-autocrypt/issues/1). I'd be happy to work with you on this, i think it's very cool! --dkg
signature.asc
Description: PGP signature
_______________________________________________ notmuch mailing list -- [email protected] To unsubscribe send an email to [email protected]
