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
signature.asc
Description: Digital signature
