Re: Autocrypt and encrypted/signed mail from a key in pubring

2019-08-23 Thread Eike Rathke
Hi,

On Thursday, 2019-08-22 22:11:41 +0200, Eike Rathke wrote:

> I don't want the automatically scanned autocrypt keys populate my
> regular keyring. I think the better solution at least for me is to sync
> the autocrypt pubring from the regular pubring.

Just to acknowledge that this method works.

  gpg --export --export-options export-clean | gpg --homedir 
$HOME/.mutt/autocrypt --import --import-options keep-ownertrust

Or, if keep-ownertrust was not specified, afterwards use

  gpg --export-ownertrust | gpg --homedir $HOME/.mutt/autocrypt 
--import-ownertrust

The signatures of encrypted and signed mails of trusted keys present in
autocrypt then are verified as trusted.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt and encrypted/signed mail from a key in pubring

2019-08-22 Thread Eike Rathke
Hi,

On Tuesday, 2019-08-20 15:42:13 -0700, Kevin J. McCarthy wrote:

> On Sun, Aug 18, 2019 at 03:29:50PM -0700, Kevin J. McCarthy wrote:
> > Another choice would be to point $autocrypt_dir at ~/.gnupg (you can
> > copy the autocrypt.db file over to save yourself having to recreate
> > accounts).  However, this will then cause Autocrypt header keys to be
> > imported into ~/.gnupg.  If that's okay with you, this will give you Web
> > of Trust signature messages instead.
> 
> After thinking it over for a few days, I've updated the manual to recommend
> pointing $autocrypt_dir to ~/.gnupg if you want to use your existing key.  I
> recommend you do so too if you still want to share the same key.

I don't want the automatically scanned autocrypt keys populate my
regular keyring. I think the better solution at least for me is to sync
the autocrypt pubring from the regular pubring.

Thanks for wrapping your head around this topic :-)

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt and encrypted/signed mail from a key in pubring

2019-08-20 Thread Kevin J. McCarthy

On Sun, Aug 18, 2019 at 03:29:50PM -0700, Kevin J. McCarthy wrote:
Another choice would be to point $autocrypt_dir at ~/.gnupg (you can 
copy the autocrypt.db file over to save yourself having to recreate 
accounts).  However, this will then cause Autocrypt header keys to be 
imported into ~/.gnupg.  If that's okay with you, this will give you 
Web of Trust signature messages instead.


After thinking it over for a few days, I've updated the manual to 
recommend pointing $autocrypt_dir to ~/.gnupg if you want to use your 
existing key.  I recommend you do so too if you still want to share the 
same key.


I could reverse the order, but this would then just lead to the reverse 
problem: missing key signature verification errors for Autocrypt 
messages.  So in the end, I think copying the key over is a bad strategy 
and recommend against it in the manual.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt and encrypted/signed mail from a key in pubring

2019-08-18 Thread Kevin J. McCarthy

On Sun, Aug 18, 2019 at 03:29:50PM -0700, Kevin J. McCarthy wrote:
Another choice would be to point $autocrypt_dir at ~/.gnupg (you can 
copy the autocrypt.db file over to save yourself having to recreate 
accounts).


Actually, peer keys would be in the database but not keyring if you just 
copied the database over.  If you do that, you should empty out the 
database peer table too.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt and encrypted/signed mail from a key in pubring

2019-08-18 Thread Kevin J. McCarthy

On Mon, Aug 19, 2019 at 12:04:14AM +0200, Eike Rathke wrote:

For an encrypted and signed mail for which the key is both in the
regular pubring and in the autocrypt pubring (and autocrypt.db), the
signature apparently is verified using the autocrypt keyring.


Yes, this is currently a problem with putting the key in both keyrings. 
Take another look at 
 
and especially read the third paragraph there.


Another choice would be to point $autocrypt_dir at ~/.gnupg (you can 
copy the autocrypt.db file over to save yourself having to recreate 
accounts).  However, this will then cause Autocrypt header keys to be 
imported into ~/.gnupg.  If that's okay with you, this will give you 
Web of Trust signature messages instead.


I've been debating switching the order, to try decrypting from the 
normal keyring first instead.  That would remove the need for 
$autocrypt_reply.  However it makes the logic more complicated and 
invasive.  We need to turn off "normal" error handling all over the 
place then, so that an initial decrypt failure in both classic-pgp and 
gpgme don't cause an abort, but only if we would subsequently be trying 
autocrypt.  Right now, the changes are in gpgme only, and are very 
clean...


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-13 Thread Eike Rathke
Hi,

On Tuesday, 2019-08-13 02:59:28 +0200, Eike Rathke wrote:

> On Monday, 2019-08-12 17:38:16 -0700, Kevin J. McCarthy wrote:
> 
> > On the plus side, it actually gives you some flexibility if you wanted to
> > take advantage of it.  You could create a different base64 export of the
> > same keyid, each with a single uid, and store it right in the database with
> > some work.  That would massively trim the size of your Autocrypt header down
> > while still being able to use the same keyid for each.
> 
> Nice aspect, I'll try that (another day).

That indeed works and cuts keydata to 2940 bytes or such. At the second
try after I realized that the base64 data needs to be unwrapped, so

  gpg  --export --export-options export-minimal --export-filter 
keep-uid="mbox=$x" 0xKEYID | base64 --wrap=0

Thanks
  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-12 Thread Eike Rathke
Hi Kevin,

On Monday, 2019-08-12 17:38:16 -0700, Kevin J. McCarthy wrote:

> On the plus side, it actually gives you some flexibility if you wanted to
> take advantage of it.  You could create a different base64 export of the
> same keyid, each with a single uid, and store it right in the database with
> some work.  That would massively trim the size of your Autocrypt header down
> while still being able to use the same keyid for each.

Nice aspect, I'll try that (another day).

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-12 Thread Eike Rathke
Hi Kevin,

On Monday, 2019-08-12 16:13:16 -0700, Kevin J. McCarthy wrote:

> On Tue, Aug 13, 2019 at 12:56:37AM +0200, Eike Rathke wrote:
> > and then  gpg --homedir testdir -k   lists the 12 (!) addresses of the
> > original key. It seems that the Autocrypt header content for an existing
> > key is pulled from the original keyring and not the ~/.mutt/autocrypt
> > keyring.
> 
> The base64 keydata is stored in the sqlite3 database once the account is
> created.  Updating the key in gpg subsequent to that won't have an effect on
> the keydata.
> 
> Make sure to remove the account (via ) and recreate it
> if you modify or re-import the key.

ARGHL.. that's it!
Then the header is half the size.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-12 Thread Kevin J. McCarthy

On Mon, Aug 12, 2019 at 04:13:16PM -0700, Kevin J. McCarthy wrote:
The base64 keydata is stored in the sqlite3 database once the account 
is created.  Updating the key in gpg subsequent to that won't have an 
effect on the keydata.


Make sure to remove the account (via ) and 
recreate it if you modify or re-import the key.


By the way, when I first implemented autocrypt, that seemed like a good 
idea.  The ECC keys were all generated by Mutt and should be unchanging.


However, now with other keys coming into the equation, it seems like 
this could become a pain point.  Do you think it would be better to add 
a warning to the documentation, or to change to regenerate (export and 
base64) the data for each Autocrypt header generation.


On the plus side, it actually gives you some flexibility if you wanted 
to take advantage of it.  You could create a different base64 export of 
the same keyid, each with a single uid, and store it right in the 
database with some work.  That would massively trim the size of your 
Autocrypt header down while still being able to use the same keyid for 
each.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-12 Thread Kevin J. McCarthy

On Tue, Aug 13, 2019 at 12:56:37AM +0200, Eike Rathke wrote:

and then  gpg --homedir testdir -k   lists the 12 (!) addresses of the
original key. It seems that the Autocrypt header content for an existing
key is pulled from the original keyring and not the ~/.mutt/autocrypt
keyring.


The base64 keydata is stored in the sqlite3 database once the account is 
created.  Updating the key in gpg subsequent to that won't have an 
effect on the keydata.


Make sure to remove the account (via ) and recreate 
it if you modify or re-import the key.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-12 Thread Eike Rathke
Hi Kevin,

On Monday, 2019-08-12 09:07:49 -0700, Kevin J. McCarthy wrote:

> On Mon, Aug 12, 2019 at 11:57:14AM +0200, Eike Rathke wrote:
> > Tried (then it needs to be done with --export-secret-keys not --export,
> > of course..) with 6 of 12 uids but that didn't change anything. I think
> > the size is merely due to the rsa4096 used on that key.
> 
> How many lines is the Autocrypt header, again?  I've seen other rsa4096 keys
> where the header is around 45 lines.  GPGME_EXPORT_MODE_MINIMAL should be
> removing all extraneous signatures, so there is no reason for it to be much
> bigger than that.

So, this is completely odd and appears to be some bug. I verified that
gpg --homedir ~/.mutt/autocrypt -K  (and -k as well) both list 6 mbox
addresses. The Autocrypt header of a mail written from such address is
203 lines, 15585 bytes with folding, I piped it through

  formail -cxAutocrypt: | sed -e 's/.*keydata=//;s/[ \t]//g' | base64 -d | gpg 
--homedir testdir --import

and then  gpg --homedir testdir -k   lists the 12 (!) addresses of the
original key. It seems that the Autocrypt header content for an existing
key is pulled from the original keyring and not the ~/.mutt/autocrypt
keyring.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-12 Thread Kevin J. McCarthy

On Mon, Aug 12, 2019 at 11:57:14AM +0200, Eike Rathke wrote:

Tried (then it needs to be done with --export-secret-keys not --export,
of course..) with 6 of 12 uids but that didn't change anything. I think
the size is merely due to the rsa4096 used on that key.


How many lines is the Autocrypt header, again?  I've seen other rsa4096 
keys where the header is around 45 lines.  GPGME_EXPORT_MODE_MINIMAL 
should be removing all extraneous signatures, so there is no reason for 
it to be much bigger than that.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-12 Thread Eike Rathke
Hi Kevin,

On Sunday, 2019-08-11 13:44:53 -0700, Kevin J. McCarthy wrote:

> On Sun, Aug 11, 2019 at 10:24:42PM +0200, Eike Rathke wrote:
> > The minimal public key of multiple UIDs written as autocrypt keydata in
> > my case is 15kB, quite large as mail overhead.  I guess there's no way
> > to reduce that somehow?
> 
> Ouch, that's pretty excessive.  When generating the Base64 keydata for the
> header, Mutt uses gpgme_op_export_keys() with the GPGME_EXPORT_MODE_MINIMAL
> flag.  I don't think there's much more Mutt can do as the keydata is
> supposed to have the uid field.
> 
> > Command line gnupg has filter options like
> > 
> >  gpg --export --export-options export-minimal --export-filter 
> > keep-uid="mbox=f...@example.com" 0xKEYID
> > 
> > which ends up with 3kB Ascii-armored per uid.
> 
> It might be worth doing this when copying over and trimming down the uid
> list as much as possible.

Tried (then it needs to be done with --export-secret-keys not --export,
of course..) with 6 of 12 uids but that didn't change anything. I think
the size is merely due to the rsa4096 used on that key.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-11 Thread Kevin J. McCarthy

On Sun, Aug 11, 2019 at 10:24:42PM +0200, Eike Rathke wrote:
The minimal public key of multiple UIDs written as autocrypt keydata in 
my case is 15kB, quite large as mail overhead.  I guess there's no way 
to reduce that somehow?


Ouch, that's pretty excessive.  When generating the Base64 keydata for 
the header, Mutt uses gpgme_op_export_keys() with the 
GPGME_EXPORT_MODE_MINIMAL flag.  I don't think there's much more Mutt 
can do as the keydata is supposed to have the uid field.



Command line gnupg has filter options like

 gpg --export --export-options export-minimal --export-filter 
keep-uid="mbox=f...@example.com" 0xKEYID

which ends up with 3kB Ascii-armored per uid.


It might be worth doing this when copying over and trimming down the uid 
list as much as possible.



Just due to rebuilding the header cache once without explicitly
switching it off for an autocrypt scan.


While there will be *some* slowdown due to Autocrypt, it shouldn't
be that noticeable.


I didn't notice a negative impact on regular mail use.


That's good to hear.  The past year I've switched over to SSD and was 
worried I might be blind to normal disk access issues.  sqlite3 should 
have acceptable performance for this usage though.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-11 Thread Eike Rathke
Hi Kevin,

On Friday, 2019-08-09 14:31:55 -0700, Kevin J. McCarthy wrote:

> On Fri, Aug 09, 2019 at 11:14:06PM +0200, Eike Rathke wrote:
> > > It's selecting a key from the keyring in $autocrypt_dir.
> > 
> > But that's just after it created the $autocrypt_dir so there's nothing
> > to select from.. I would had expected it offers to select from the
> > general gnupg keyring.
> 
> The "first run" account creation process can take place even if
> $autocrypt_dir already exists.  Account creation also can take place from
> the .  This feature is to allow using the same key
> across multiple accounts, or to use a key that *you* have imported yourself.

Tried that and it works. The minimal public key of multiple UIDs written
as autocrypt keydata in my case is 15kB, quite large as mail overhead.
I guess there's no way to reduce that somehow? Command line gnupg has
filter options like

  gpg --export --export-options export-minimal --export-filter 
keep-uid="mbox=f...@example.com" 0xKEYID

which ends up with 3kB Ascii-armored per uid.


> I've updated the documentation at
>  to make this
> specific, and added a section "Alternative Key and Keyring Strategies" to
> discuss the ways and caveats of sharing keys or keyrings.

Nice, thanks.


> > > [... header cache invalidation ...]
> > I'll plan for two mugs of coffee when I throw this against IMAP with
> > folders of 6-8 messages.. :-P
> 
> Are you seeing horrific performance specifically because of the autocrypt
> header scanning, or just in general due to having to rebuild the header
> cache?

Just due to rebuilding the header cache once without explicitly
switching it off for an autocrypt scan.

> While there will be *some* slowdown due to Autocrypt, it shouldn't
> be that noticeable.

I didn't notice a negative impact on regular mail use.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-09 Thread Kevin J. McCarthy

On Fri, Aug 09, 2019 at 11:14:06PM +0200, Eike Rathke wrote:

It's selecting a key from the keyring in $autocrypt_dir.


But that's just after it created the $autocrypt_dir so there's nothing 
to select from.. I would had expected it offers to select from the 
general gnupg keyring.


The "first run" account creation process can take place even if 
$autocrypt_dir already exists.  Account creation also can take place 
from the .  This feature is to allow using the same 
key across multiple accounts, or to use a key that *you* have imported 
yourself.


I've updated the documentation at 
 to make 
this specific, and added a section "Alternative Key and Keyring 
Strategies" to discuss the ways and caveats of sharing keys or keyrings.


This is likely because the changes to Mutt data structures (to add the 
autocrypt fields) invalidated the header cache.  I didn't mention it 
in the docs because that would make the issue more confusing.


I'll plan for two mugs of coffee when I throw this against IMAP with 
folders of 6-8 messages.. :-P


Are you seeing horrific performance specifically because of the 
autocrypt header scanning, or just in general due to having to rebuild 
the header cache?  While there will be *some* slowdown due to Autocrypt, 
it shouldn't be that noticeable.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-09 Thread Eike Rathke
Hi Kevin,

On Thursday, 2019-08-08 15:58:07 -0700, Kevin J. McCarthy wrote:

> On Fri, Aug 09, 2019 at 12:36:37AM +0200, Eike Rathke wrote:
> > > Yes, today I pushed up the ability to select a key during account 
> > > creation.
> > > It's rather fresh but I think works okay.
> > 
> > Tried that and did (s)elect existing GPG key, but got "No secret key
> > found". Didn't dig deeper.
> 
> It's selecting a key from the keyring in $autocrypt_dir.

But that's just after it created the $autocrypt_dir so there's nothing
to select from.. I would had expected it offers to select from the
general gnupg keyring.


> > The docs say that "header cached messages are not re-scanned for
> > Autocrypt headers", however, my gut feeling is that mailboxes not yet
> > scanned are scanned when opening them the first time after autocrypt was
> > initialized, even if header caching is on.
> 
> This is likely because the changes to Mutt data structures (to add the
> autocrypt fields) invalidated the header cache.  I didn't mention it in the
> docs because that would make the issue more confusing.

I'll plan for two mugs of coffee when I throw this against IMAP with
folders of 6-8 messages.. :-P

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-08 Thread Kevin J. McCarthy

On Fri, Aug 09, 2019 at 12:36:37AM +0200, Eike Rathke wrote:

Yes, today I pushed up the ability to select a key during account creation.
It's rather fresh but I think works okay.


Tried that and did (s)elect existing GPG key, but got "No secret key
found". Didn't dig deeper.


It's selecting a key from the keyring in $autocrypt_dir.


I also added $autocrypt_reply to turn off the "forced autocrypt" mode when
replying.  If the same key is used in both web-of-trust and autocrypt, it
may be more convenient to choose yourself when replying rather than have
autocrypt force itself on you each time.


Makes sense. Though with several accounts some (which don't have a WoT
key assigned) may be preferred using autocrypt_reply and others not, so
probably a sender address hook (reply-hook) would be appropriate. Would
that work?


Yes, crypto setting are set after the initial message editing.


Btw, how about passphrases for autocrypt keys? Recommendation is to not
have such or not ask it for every mail, but I'd not use a regular key
without passphrase for autocrypt. Is the usual PGP passphrase handling
(including timeout) also applied to autocrypt keys? Maybe I'll find some
time over the weekend to play around with things.. until then I ask
stupid questions ;-)


Autocrypt uses GPGME.  I'd suspect it would honor agent configuration 
settings set in $autocrypt_dir, but I haven't tested it.



The docs say that "header cached messages are not re-scanned for
Autocrypt headers", however, my gut feeling is that mailboxes not yet
scanned are scanned when opening them the first time after autocrypt was
initialized, even if header caching is on.


This is likely because the changes to Mutt data structures (to add the 
autocrypt fields) invalidated the header cache.  I didn't mention it in 
the docs because that would make the issue more confusing.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-08 Thread Eike Rathke
Hi Kevin,

On Wednesday, 2019-08-07 17:40:06 -0700, Kevin J. McCarthy wrote:

> > One caveat: when enabling autocrypt=yes and starting mutt the first time
> > one must ensure to not have some key push in the config, otherwise that
> > interferes with the prompt about setting up the autocrypt directory.
> > BTDT..
> 
> Whoops - there's one right there.  I'll fix that in the next couple days.

I confirm it works now.

> > Questions remaining: it may be possible to use an already existing RSA
> > key imported from the GnuPG keyring. At least I've seen such Autocrypt
> > keys even with two accounts on them. Does Mutt Autocrypt support that?
> 
> Yes, today I pushed up the ability to select a key during account creation.
> It's rather fresh but I think works okay.

Tried that and did (s)elect existing GPG key, but got "No secret key
found". Didn't dig deeper.

> I also added $autocrypt_reply to turn off the "forced autocrypt" mode when
> replying.  If the same key is used in both web-of-trust and autocrypt, it
> may be more convenient to choose yourself when replying rather than have
> autocrypt force itself on you each time.

Makes sense. Though with several accounts some (which don't have a WoT
key assigned) may be preferred using autocrypt_reply and others not, so
probably a sender address hook (reply-hook) would be appropriate. Would
that work?

Btw, how about passphrases for autocrypt keys? Recommendation is to not
have such or not ask it for every mail, but I'd not use a regular key
without passphrase for autocrypt. Is the usual PGP passphrase handling
(including timeout) also applied to autocrypt keys? Maybe I'll find some
time over the weekend to play around with things.. until then I ask
stupid questions ;-)

The docs say that "header cached messages are not re-scanned for
Autocrypt headers", however, my gut feeling is that mailboxes not yet
scanned are scanned when opening them the first time after autocrypt was
initialized, even if header caching is on. At least I experienced
a quite slow scanning for larger mailboxes in such first visits. If so,
this can be a problem for large IMAP boxes, but was already slow enough
for large local boxes.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature


Re: Autocrypt

2019-08-07 Thread Kevin J. McCarthy

On Thu, Aug 08, 2019 at 01:06:23AM +0200, Eike Rathke wrote:

The new Autocrypt feature seems to work :-)
Tried with/without overriding conventional PGP encryption and vice
versa. Great work, thanks!


Thanks for testing it out, Eike!  It's pretty new, so I'm sure there are 
still plenty of issues.



One caveat: when enabling autocrypt=yes and starting mutt the first time
one must ensure to not have some key push in the config, otherwise that
interferes with the prompt about setting up the autocrypt directory.
BTDT..


Whoops - there's one right there.  I'll fix that in the next couple 
days.



Questions remaining: it may be possible to use an already existing RSA
key imported from the GnuPG keyring. At least I've seen such Autocrypt
keys even with two accounts on them. Does Mutt Autocrypt support that?


Yes, today I pushed up the ability to select a key during account 
creation.  It's rather fresh but I think works okay.


I also added $autocrypt_reply to turn off the "forced autocrypt" mode 
when replying.  If the same key is used in both web-of-trust and 
autocrypt, it may be more convenient to choose yourself when replying 
rather than have autocrypt force itself on you each time.


I still need to update the documentation but will do that today or 
tomorrow.



On the other hand, would it make sense to do so? Or are there advantages
on having separate keys per account? Apart from they can be revoked or
changed individually.


I don't think there's anything wrong with using the same key for 
multiple accounts.  Others may have opinions on this though.


The only caveat is the UID in the key would be the same.  As long as the 
shared identity isn't something you want to keep hidden that shouldn't 
be a problem.  Autocrypt implementations should use the header, not the 
UID, to look up the correct key.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature