Re: [Mutt] #2448: S/MIME decrypting keyid selection
#2448: S/MIME decrypting keyid selection
Changes (by brendan):
* component: mutt => crypto
Old description:
> {{{
>
> Hello,
>
> There are some problems with S/MIME decrypting key selection, when
> one has multiple keys, and has unset $smime_decrypt_use_default_key:
>
> -1) Before each display of a crypted message, Mutt iteratively prompts
> for the decrypting key to use:
>
> | Use ID 12345678.1 for email@xxxxxxxxxxx ? ([no]/yes):
> | Use ID 12345678.2 for email@xxxxxxxxxxx ? ([no]/yes):
> | Use ID 12345678.x for email@xxxxxxxxxxx ? ([no]/yes):
> | Use ID 12345678.0 for email@xxxxxxxxxxx ? ([no]/yes):
> | Enter keyID for email@xxxxxxxxxxx:
>
> ...and finally shows the smime menu listing all available private
> keys, even for other email addreses:
>
> | S/MIME certificates matching "".
>
> That's not very practical, given that:
>
> - User may not know which encrypting key was used.
> - User may not remember which 12345678.x selects the wanted key
> (display the certficate's label would help).
> - The firsts y/n prompts are disordered: The last prompted ".0" was the
> first in ~/.smime/keys/.index
> - The labels are displayed only at the 6th step, the key listing.
> - Each selection of a different keyid wipes the passphrase.
> - There is no error on misselected keyid, just an empty body.
> - There is no error on mistyped passphrase, just an empty body.
> - The whole sequence restarts each time user does <view-attachments>,
> <exit><display-message>, <display-toggle-weed>, or goes to view another
> crypted message.
>
> Possible solutions:
>
> -a) Is there really no full automatic way to guess which key
> encrypted the message?
>
> -b) Could we store as many passphrases as keyids? Or optionally a
> single passphrase for all keyids? The current halfway scheme doesn't
> seem to make much sense.
>
> -c) In such long iterative selection sequences, shouldn't there be a
> shortcut to go directly to the listing? Maybe something similar to "?"
> at <change-folder> prompt going to browser, or yet another $option.
>
> Further problems:
>
> -2) <decrypt-copy> and <decrypt-save> dont't prompt for a key, nor
> passphrase, and won't decrypt. Result is original crypted mail.
>
> -3) <decode-copy> and <decode-save> do prompt for a passphrase, but not
> for a keyid. If crypted message, last selected keyid, and passphrase are
> matching: Result is the expected decoded and decrypted message.
> Otherwise result is a message with silently lost empty body. Without any
> error nor warning.
>
> -4) Doing <view-attachments> on an S/MIME opaque signed message (that
> is *not* crypted) uselessly starts the keyid selection sequence (but
> doesn't prompt for a passphrase).
>
> Bye! Alain.
> >How-To-Repeat:
> >Fix:
> }}}
New description:
{{{
Hello,
There are some problems with S/MIME decrypting key selection, when
one has multiple keys, and has unset $smime_decrypt_use_default_key:
-1) Before each display of a crypted message, Mutt iteratively prompts
for the decrypting key to use:
| Use ID 12345678.1 for email@xxxxxxxxxxx ? ([no]/yes):
| Use ID 12345678.2 for email@xxxxxxxxxxx ? ([no]/yes):
| Use ID 12345678.x for email@xxxxxxxxxxx ? ([no]/yes):
| Use ID 12345678.0 for email@xxxxxxxxxxx ? ([no]/yes):
| Enter keyID for email@xxxxxxxxxxx:
...and finally shows the smime menu listing all available private
keys, even for other email addreses:
| S/MIME certificates matching "".
That's not very practical, given that:
- User may not know which encrypting key was used.
- User may not remember which 12345678.x selects the wanted key
(display the certficate's label would help).
- The firsts y/n prompts are disordered: The last prompted ".0" was the
first in ~/.smime/keys/.index
- The labels are displayed only at the 6th step, the key listing.
- Each selection of a different keyid wipes the passphrase.
- There is no error on misselected keyid, just an empty body.
- There is no error on mistyped passphrase, just an empty body.
- The whole sequence restarts each time user does <view-attachments>,
<exit><display-message>, <display-toggle-weed>, or goes to view another
crypted message.
Possible solutions:
-a) Is there really no full automatic way to guess which key
encrypted the message?
-b) Could we store as many passphrases as keyids? Or optionally a
single passphrase for all keyids? The current halfway scheme doesn't
seem to make much sense.
-c) In such long iterative selection sequences, shouldn't there be a
shortcut to go directly to the listing? Maybe something similar to "?"
at <change-folder> prompt going to browser, or yet another $option.
Further problems:
-2) <decrypt-copy> and <decrypt-save> dont't prompt for a key, nor
passphrase, and won't decrypt. Result is original crypted mail.
-3) <decode-copy> and <decode-save> do prompt for a passphrase, but not
for a keyid. If crypted message, last selected keyid, and passphrase are
matching: Result is the expected decoded and decrypted message.
Otherwise result is a message with silently lost empty body. Without any
error nor warning.
-4) Doing <view-attachments> on an S/MIME opaque signed message (that
is *not* crypted) uselessly starts the keyid selection sequence (but
doesn't prompt for a passphrase).
Bye! Alain.
>How-To-Repeat:
>Fix:
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2448#comment:1>