Encrypting when possible
I've been working on this patch series for a while, and finally committed it to the repository yesterday. For those of you who would like to encrypt by default and don't mind compiling from the repository, please check it out. To use it, just put set crypt_opportunistic_encrypt in your muttrc. Caveats: - If something else, e.g. $crypt_autoencrypt or $crypt_replyencrypt, enables encryption, this option will be disabled for that message. It can be manually turned back on in the pgp menu. - An unverified (not in your web of trust) key will be used as a candidate to possibly enable encryption. However, when you send the message, Mutt will still prompt to confirm whether you want to use the key. -Kevin signature.asc Description: PGP signature
Re: Encrypting when possible
++ 31/03/15 11:47 -0700 - Kevin J. McCarthy: I've been working on this patch series for a while, and finally committed it to the repository yesterday. For those of you who would like to encrypt by default and don't mind compiling from the repository, please check it out. That sounds like a welcome feature. I have a encrypt by default policy and I have solved it by running a script on a daily basis that generates send-hooks for all e-mailaddress that it can find in my public keyring. So, a better solution is most welcome. :) To get a copy of your code, I just need to clone the default branch from the Mercurial repository? I haven't had a look at the code yet, but can you explain how it does work (e.g. how does it determine when there's a key for a recipient on the keyring and encrypting is feasable and when it is not)? Additionaly, may I draw your attention to these two tickets: - http://dev.mutt.org/trac/ticket/3727, which is patch to allow for encryption to multiple keys based on a single recipient (which is usefull when sending encrypted mail to mailinglist with a static set of subscribers) - http://dev.mutt.org/trac/ticket/3728, which is a bugreport for a case in which users are not able to read application/pgp-encrypted attachments (unless the user saves the attachments and runs gpg and openssl manually on the saved message part) Not sure if you can do anything with those, but the first one is ready to implement (I am using the patch myself on a daily basis). -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 pgp_2WhxG69n3.pgp Description: PGP signature
Re: Encrypting when possible
Rejo Zenger wrote: ++ 31/03/15 11:47 -0700 - Kevin J. McCarthy: I've been working on this patch series for a while, and finally committed it to the repository yesterday. For those of you who would like to encrypt by default and don't mind compiling from the repository, please check it out. To get a copy of your code, I just need to clone the default branch from the Mercurial repository? Yes, it's in the default branch in the Mercurial repository. I haven't had a look at the code yet, but can you explain how it does work (e.g. how does it determine when there's a key for a recipient on the keyring and encrypting is feasable and when it is not)? It uses the same routines that Mutt uses when you go to send a message, but it takes away any prompting. It looks for an email-address match (or crypt-hook with a key) for each recipient. If all recipients have a key, it enables encryption. Otherwise it disables encryption. This happens whenever the To, Cc, or Bcc list is edited, or when the message is edited if $edit_headers is set. A word of caution though, this patch series significantly changed the code that ticket 3727 applies to, so I doubt that patch will apply without some re-working. Additionaly, may I draw your attention to these two tickets: - http://dev.mutt.org/trac/ticket/3727, which is patch to allow for encryption to multiple keys based on a single recipient (which isusefull when sending encrypted mail to mailinglist with a static setof subscribers) - http://dev.mutt.org/trac/ticket/3728, which is a bugreport for a case in which users are not able to read application/pgp-encrypted attachments (unless the user saves the attachments and runs gpg and openssl manually on the saved message part) Thanks for opening the tickets. I can't guarantee a timeline, but I'll put those on my radar to look at. -Kevin signature.asc Description: PGP signature
