You could set (and store across postpone / resume) a flag in msg->security that indicates that the user mangled with the encryption settings, which would then override opportunistic encryption in the future, for this message.
On 2013-10-26, at 05:46 +0200, Kevin J. McCarthy <ke...@8t8.us> wrote:
> Michael Elkins wrote:
>> I see a potential problem here: If the user has manually requested
>> encryption or disabled it for the current message, but has
>> opportunistic encryption enabled, it may override what the user has
>> set manually.
>
> That's a good point. Right now I can think of three imperfect ideas:
>
> 1. Set a local variable that temporarily disables opportunistic encrypt
> if they change the message encryption bit.
> Unfortunately the local variable flag would be lost with a
> postpone/resume.
>
> int mutt_compose_menu (...)
> {
> int disable_opp_enc = 0;
>
> case OP_COMPOSE_PGP_MENU: /* also for OP_COMPOSE_SMIME_MENU */
> int old_enc = (msg->security & ENCRYPT);
> msg->security = crypt_pgp_send_menu (msg, &menu->redraw);
> if (old_enc != (msg->security & ENCRYPT))
> disable_opp_enc = 1;
>
> case OP_COMPOSE_EDIT_TO:
> if (option (OPTCRYPTOPPORTUNISTICENCRYPT) &&
> (! disable_opp_enc))
> {
> crypt_opportunistic_encrypt (msg);
> redraw_crypt_lines (msg);
> }
>
> 2. A message warning that opportunistic encrypt is set if they change
> the encrypt value manually, along with a prompt to turn it off.
> This would be lost with a postpone/resume across different mutt
> sessions, however. The user might also be surprised the option was
> completely turned off.
>
> case OP_COMPOSE_PGP_MENU:
> int old_enc = (msg->security & ENCRYPT);
> msg->security = crypt_pgp_send_menu (msg, &menu->redraw);
> if (option (OPTCRYPTOPPORTUNISTICENCRYPT) &&
> old_enc != (msg->security & ENCRYPT) &&
> (mutt_yesorno (_("Opportunistic encrypt is set and may override your
> change. Disable opportunistic encrypt?"), M_YES) == M_YES))
> {
> unset_option(OPTCRYPTOPPORTUNISTICENCRYPT);
> }
>
> 3. Documenting the behavior and warning the user the option will
> override manual encryption changes when turned on.
>
> Do any of these ideas seem acceptable? Can you think of a better
> approach?
>
>> The same problem would also appear for a user doing this:
>>
>> set crypt_opportunistic_encrypt
>> send-hook . unset crypt_autoencrypt
>> send-hook @mycompany.com set crypt_autoencrypt
>>
>> The intent here is that I want to *always* encrypt when sending to
>> my colleagues, but opportunistically encrypt whenever I can when
>> sending elsewhere.
>
> I think this is fixable by adding a check for
> option(OPTCRYPTAUTOENCRYPT) being set inside the
> crypt_opportunistic_encrypt() function. If it's set, then
> crypt_opportunistic_encrypt() will abort.
>
>> Perhaps the user interface should look like this:
>>
>> set crypt_autoencrypt
>> send-hook . unset crypt_require_encrypt
>> send-hook @mycompany.com set crypt_require_encrypt
>>
>> So $crypt_autoencrypt will encrypt when it can, and fail when
>> $crypt_require_encrypt is set and not all keys can be found.
>
> I like your suggested configuration variable names. They better
> represent the intended meaning of each option. The cost would be a
> surprising behavior change in crypt_autoencrypt that could lead to some
> enraged users.
>
> With your blessing I'd be glad to submit a different
> patch series renaming crypt_autoencrypt => crypt_require_encrypt and
> then changing this patch series to use the option crypt_autoencrypt.
>
> -Kevin
Thomas Roessler (@roessler)
signature.asc
Description: Message signed with OpenPGP using GPGMail
