Re: [PATCH v2 0/2] scaffolding for autocrypt support
Hi, I just wanted to note that the backend system in autocrypt.el was reworked, and that this patch should probably be adapted, in case the maintainers are still interested. The details are documented here[0]. The intention is to make extensions like these simpler, and removing direct dependencies on autocrypt.el. [0] https://git.sr.ht/~pkal/autocrypt#extending-codeautocryptelcode ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 0/2] scaffolding for autocrypt support
On Friday, 2021-04-16 at 09:05:29 -03, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> Hi David, all-- >> >> On Sun 2021-02-21 15:21:30 +, David Edmondson wrote: >>> I started looking at how to add autocrypt support based on >>> https://git.sr.ht/~zge/autocrypt. >> >> Thanks for this work, i'm glad to see the interest in autocrypt! >> >> I tend to think that the autocrypt handling belongs in libnotmuch, and >> not just in the emacs frontend, so i'm a bit concerned about what we'll >> have to prune out of the emacs frontend if we do manage to land the >> features in libnotmuch itself. > > FTR, I'm waiting for the two of you to come to some concensus before > proceding with these patches. At the moment I don't really have time to make any progress, sorry. dme. -- Welcome to Conditioning. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 0/2] scaffolding for autocrypt support
Daniel Kahn Gillmor writes: > Hi David, all-- > > On Sun 2021-02-21 15:21:30 +, David Edmondson wrote: >> I started looking at how to add autocrypt support based on >> https://git.sr.ht/~zge/autocrypt. > > Thanks for this work, i'm glad to see the interest in autocrypt! > > I tend to think that the autocrypt handling belongs in libnotmuch, and > not just in the emacs frontend, so i'm a bit concerned about what we'll > have to prune out of the emacs frontend if we do manage to land the > features in libnotmuch itself. FTR, I'm waiting for the two of you to come to some concensus before proceding with these patches. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 0/2] scaffolding for autocrypt support
Hi David, all--
On Sun 2021-02-21 15:21:30 +, David Edmondson wrote:
> I started looking at how to add autocrypt support based on
> https://git.sr.ht/~zge/autocrypt.
Thanks for this work, i'm glad to see the interest in autocrypt!
I tend to think that the autocrypt handling belongs in libnotmuch, and
not just in the emacs frontend, so i'm a bit concerned about what we'll
have to prune out of the emacs frontend if we do manage to land the
features in libnotmuch itself.
I want it in libnotmuch and in the cli because:
a) i want the database to hold the autocrypt tables, so that it can be
dumped/restored between notmuch-based clients
b) i want non-emacs frontends of notmuch to be able to make use of it
relatively easily.
that said, i've failed to get the code into shape for libnotmuch yet,
and i also don't want to block this work -- i want to see more autocrypt
adoption generally, and i'm feeling guilty for having been so tardy in
getting ito into notmuch.
My general outline for getting autocrypt into notmuch is the following
list of steps. it's a fairly long list, but each step shouldn't be a
huge amount of work.
0) augment the database so that it can store the autocrypt "peers"
table and the autocrypt "accounts" table, and they can be dumped and
restored. see
https://autocrypt.org/level1.html#autocrypt-internal-state
1) add a configuration option that affects "notmuch
{new,insert,reindex}" that ingests the loading of autocrypt headers
according to the standard policy for updating the peer state (see
https://autocrypt.org/level1.html#updating-autocrypt-peer-state)
2) add a configuration option that affects "notmuch
{new,insert,reindex}" that enables detection of any Autocrypt Setup
Message from another client sharing the same inbox, and adjusts the
"accounts" table appropriately.
3) add a "notmuch autocrypt" subcommand with its own subsubcommands:
"notmuch autocrypt enable [mutual]" and "notmuch autocrypt
disable " -- these subsubcommands update the "accounts" table
as well.
4) add "notmuch autocrypt generate-setup-message" subsubcommand for
enabled accounts that produces its own self-targeted Autocrypt Setup
Message on stdout, which can be injected into the mailsystem
by the user's notmuch setup.
5) Add "notmuch autocrypt prune" subsubcommand which clears accumulated
cruft from the autocrypt peers table
6) in libnotmuch, if is a source e-mail address, and is a
set of destination addresses, add is a
boolean, a new function notmuch_autocrypt_recommendation(,
, ) that returns an Autocrypt
Recommendation (ui-recommendation and a set of target-keys, see
https://autocrypt.org/level1.html#provide-a-recommendation-for-message-encryption)
7) add a new subsubcommand that exposes
notmuch_autocrypt_recommendation() to the cli.
8) emacs frontend work during message composition (i have no idea how
to do this) -- dynamically adjust the message composition buffer as
the from, to, cc, and bcc fields change to show the current
autocrypt recommendation status, in combination with the ability for
the user to manually turn on encryption (if available) or off (if on
by default).
9) more emacs frontend work -- at send time (at the end of composition)
if the autocrypt recommendation is encrypt, or if it's available and
the user has manually turned it on, encrypt the message using
standard autocrypt format (which is just PGP/MIME, using the
recommended keys).
It's possible that (9) could be replaced with a new subcommand like
"notmuch send" which could have a "--autocrypt-checked" argument, such
that the notmuch cli actually does the full encryption for the user, or
acts as some sort of filter for the outgoing message. there might also
be some library-level work that could use notmuch and gmime to translate
the message this way; I haven't really pieced those things together, or
how they would integrate into the emacs frontend, but the steps laid out
above seem to be necessary for that to happen in either case.
I'd love any collaboration on this -- especially for the parts that i
don't know how to do at all, like the emacs composition window frontend
-- but also on the earlier parts, as i've been procrastinating on it for
too long.
David, do you think this plan will collide with the series you're
proposing? do you see problems or downsides with the plan sketched here
(other than it not existing )?
> Sending seems straightforward, as far as I understand autocrypt, at
> least.
https://autocrypt.org and the #autocrypt channel on freenode are both
good resources for understanding autocrypt in more detail, fwiw.
--dkg
signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH v2 0/2] scaffolding for autocrypt support
I started looking at how to add autocrypt support based on https://git.sr.ht/~zge/autocrypt. Sending seems straightforward, as far as I understand autocrypt, at least. Dealing with inbound messages requires a few framework changes in the existing notmuch emacs code, which is these two patches. I'll send autocrypt patches after some more testing and improvement. Currently things are pretty inefficient - autocrypt-notmuch-header will request the raw message on every call, which is expensive if the message is large. v2: - Rebased on master (bremner). David Edmondson (2): emacs: with-current-notmuch-show-message should return the result of body emacs: Add notmuch-show-insert-msg-hook emacs/notmuch-show.el | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) -- 2.30.0 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 0/2] scaffolding for autocrypt support
I started looking at how to add autocrypt support based on https://git.sr.ht/~zge/autocrypt. Sending seems straightforward, as far as I understand autocrypt, at least. Dealing with inbound messages requires a few framework changes in the existing notmuch emacs code, which is these two patches. They are not autocrypt specific, and could be generally useful. I'll send autocrypt patches after some more testing and improvement. Currently things are pretty inefficient - autocrypt-notmuch-header will request the raw message on every call, which is expensive if the message is large. David Edmondson (2): emacs: with-current-notmuch-show-message should return the result of body emacs: Add notmuch-show-insert-msg-hook emacs/notmuch-show.el | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) -- 2.29.2 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Autocrypt support
* Daniel Kahn Gillmor: > [...] if you'd like to help me strategize about next steps for getting > autocrypt support into notmuch itself, i'd welcome the collaboration. I'd be willing to help if you think I can actually be of use to you. ;-) I have, as of today, not even looked at the Notmuch architecture and source code. I do know a reasonable amount about GnuPG, RFC 5322 et al, though. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Autocrypt support
On Thu 2019-04-11 16:01:43 +0200, Ralph Seichter wrote: > I'm not quite sure if this is a question of Notmuch's Emacs client or of > Emacs in general, but I am trying to find information on Autocrypt > support (see https://autocrypt.org/). > > The Enigmail addon for Thunderbird supports Autocrypt, and I wondered > if/how Notmuch might be persuaded to support it as well? yes, i want notmuch to support autocrypt, and it's been on my to-do list for many months now. :( I would love to have some help on that, because i've been a bit blocked, still trying to wrap up my protected headers series. But if you'd like to help me strategize about next steps for getting autocrypt support into notmuch itself, i'd welcome the collaboration. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Autocrypt support
I'm not quite sure if this is a question of Notmuch's Emacs client or of Emacs in general, but I am trying to find information on Autocrypt support (see https://autocrypt.org/). The Enigmail addon for Thunderbird supports Autocrypt, and I wondered if/how Notmuch might be persuaded to support it as well? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
