<<< Date Index >>>     <<< Thread Index >>>

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>