The mutt version in Debian Sarge (Unstable) is 1.5.6.
I used to be somewhat irritated with the previous behaviour of this menu
(in 1.4), since switching from sign-and-encrypt to sign-only required
two actions. I was quite pleased with the behaviour in 1.5 since it now
toggles, at least I was pleased until I read the mail below.
I have to say I agree 100% percent with Derek. The menu should be made
clearer. Thinking back I found out about the new behaviour by mistake, I
was *lucky* to notice that the buttons now toggled rather than just
turning it on. I would be in favour of having the following menu
(almost straight copy from below, (c)lear rather then (f)orget):
(e) ONLY encrypt the message (i.e. change the options to only
encrypt, regardless of what they currently are).
(s) ONLY sign the message, regardless of current options.
(a) change the key with which to sign, adding the sign option if
necessary
(b) do both, regardless of current options
(i) toggle in-line attachments (but change menu to indicate toggle)
(c) clear the encryption options
/M
On Fri, Aug 06, 2004 at 03:25:57PM +0900, Derek Martin wrote:
>I posted this on mutt-dev where it belongs, but I also wanted to give
>the users the chance to comment on this issue.
>
>On Wed, May 05, 2004 at 04:38:08PM +0900, invalid@xxxxxxxxxxxxxx wrote:
>> I downloaded the latest CVS mutt code in order to get the fix for slang.
>> I see that the encryption options menu behaviors have changed... IMNSHO
>> they've gone from bad to worse.
>
>Having just sent out an encrypted mail with the wrong options (using a
>version of mutt compiled from CVS code from about 2 months ago), I feel
>compelled to revisit the issue of the behavior of the encryption
>options menus. While this is not exactly a /vulnerability/ in Mutt,
>it does constitute a legitimate security issue. Please, please,
>please reconsider the behavior of this menu! At least, please
>consider the following discussion. I tried to submit it to the BTS
>but it seems to be broken again...
>
>For those who don't know, in CVS the new behavior of the encryption
>options menus is to TOGGLE (e)ncrypt and (s)ign.
>
>The encryption options menu provides the following options (these are
>PGP options, but the S/MIME options are similar):
>
> PGP (e)ncrypt, (s)ign, sign (a)s, (b)oth, (i)nline, or (f)orget it?
>
>By looking at these options, I'm not sure how anyone could possibly
>get the idea that, for example, pressing (e) to encrypt a message
>could actually TURN OFF encryption of the message. I personally find
>that this behavior is not only unintuitive, it's completely
>counterintuitive and potentially dangerous to the unsuspecting user.
>For that matter, it's even dangerous to the suspecting user who's
>unaccustomed to this new toggle behavior.
>
>If I press (e) to encrypt, the most obvious interpretation of these
>menu options is that encryption will be turned on. I can't see how it
>makes sense to use the same key to also turn off encryption. After
>all, we have an option for signing, and we have an option to clear all
>encryption options (the poorly named (f)orget it option). So why
>then, do we also need to toggle? When one looks at this menu, how is
>one to glean even a hint that the behavior toggles options? It is
>simply not possible. If the user didn't realize that encryption was
>already set (i.e. via a sender-hook), then the user must notice that
>encryption is not enabled, and press (e) again. The consequences
>could be potentially serious... Envision a system administrator who
>is under investigation reading accidentally unencrypted details of the
>investigation! Many other such scenarios can be imagined...
>
>Especially given that the behavior is a departure from the traditional
>mutt behavior, I think it's quite clear that this change is a bad
>change and a dangerous change. It is fine to argue that the user
>should be careful about verifying encryption options, as this point is
>very true. However, users notoriously make this kind of mistake, and
>this fact is well known. The design of the software should,
>therefore, be such that it is hard for the user to make this kind of
>mistake. The current design of this menu fails to do so, and that
>failure is a potentially serious security issue for the user who makes
>a mistake.
>
>If you really want these options to toggle, then I think the menu is
>in dire need of being completely redesigned so that this behavior is
>indicated clearly. However, there is no need to toggle given the
>current set of options, because all possible combinations could be
>acheived with one keystroke without any toggling. In fact, if the
>options toggle, more keystrkes are required to fix them. This is
>another reason why this choice of behavior is not a good one. As it
>stands, I feel rather strongly that the current behavior exemplifies
>bad UI design, and I hope that the above discussion, makes the fact
>that it is bad UI design evident to others.
>
>Given the options presented, the most obvious interpretation of what
>they do is:
>
> (e) ONLY encrypt the message (i.e. change the options to only
> encrypt, regardless of what they currently are).
> (s) ONLY sign the message, regardless of current options.
> (a) change the key with which to sign, adding the sign option if
> necessary
> (b) do both, regardless of current options
> (i) toggle in-line attachments (but change menu to indicate toggle)
> (f) clear the encryption options
>
>(b) currently behaves sensibly, turning on both options, regardless of
>what options are set. (e) and (s) do not, which is not sensible, and
>also happens to be inconsistent with the behavior of (b). (i) should
>toggle, but it should be labeled as a toggle so that this is obvious.
>Either that, or two options should be provided: one to turn it on, and
>the other to turn it off.
>
>Finally, if you press (f) to clear the options, after doing so the
>"Security:" field is shown as "Clear". The choice of the option name
>"forget it" is not only a little ugly, but also ambiguous. The name
>of this option should likewise be (c)lear, to reflect both what the
>option does, and the status that it provides.
>
>Please, please, please reconsider the behavior of this menu!
>
>I also want to encourage other list members to provide feedback about
>this issue.
>
>Thanks for listening.
>
>--
>Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
>-=-=-=-=-
>This message is posted from an invalid address. Replying to it will result in
>undeliverable mail. Sorry for the inconvenience. Thank the spammers.
>
>
>
>
>----- End forwarded message -----
>
>--
>Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
>-=-=-=-=-
>This message is posted from an invalid address. Replying to it will result in
>undeliverable mail. Sorry for the inconvenience. Thank the spammers.
>
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus@xxxxxxxxxxxx
http://magnus.therning.org/
Finagle's Second Law:
Always keep a record of data -- it indicates you've been working.
Attachment:
signature.asc
Description: Digital signature