* Andreas Henriksson <andr...@fatal.se> [200302 08:27]:
> On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote:
> > Control: -1 severity grave
> >
> > I'm increasing the severity of this bug, as it can cause unintended
> [...]
>
> I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1,
> which fixes the two other outstanding RC bugs.
> It seems I can still reproduce this issue however (with the first prompt
> I get which is the imap password prompt for me).
Thanks for this!
> This seems somewhat like a possible UX design fail.
Possibly, but I suspect not. This is a regression from previous
versions, and it would not make sense at all as an intentional design
change.
> This is done
> upstream and not in debian. Do you know if there's already been any
> discussion regarding this upstream? If not could you please file an
> upstream bug report about this?
Unfortunately, I don't have time to do this at the moment. I have no
clue where upstream's bug system (or mailing list) is, and can't spend
the time to do this right away. If you (or the maintainer; I assume you
are not the maintainer since you did an NMU) would be so kind as to
point upstream to this bug, I would appreciate it.
> The behaviour hasn't really bothered me and I probably wouldn't even
> have noticed it if it wasn't for this bug showing up on the RC bug radar
> while doing my NMU, so I'm quite tempted to downgrade severity again.
> Please work this out with upstream if this issue is important to you.
> Please give feedback on this bug report about upstream discussions or
> relevant commits and I'm happy to look into cherry-picking and NMUing
> those as needed.
Please don't downgrade this bug. Here is a very plausible expanded
example based on my original scenario:
The user is unaware of this bug, so is not being careful to watch out
when backspacing (I am now aware of this bug, and still find myself
accidentally backspacing too far).
The user has tagged a large number of messages, intending to save them
all to a different folder. The user types «;s=soon-but-not-immediate»
out of habit, without watching the command line, and doesn't notice what
folder was originally placed on the command line based on the save-hook
for the first tagged message. The first message happens to match the
save-hook for "=spam" (it received a marginally-positive spam score from
spamassassin, but was a false positive).
Before hitting enter on the ;s=soon-but-not-immediate command, the user
changes his mind and decides to save them to the =handle-now folder, so
he presses and holds the backspace key.
Oops! Now all those messages are moved to the spam folder, which
triggers a daemon on the IMAP server to tell spamassassin to learn all
those messages as spam and moves the messages into a quarantine folder
(inaccessible to the user).
Meanwhile, the poor user, who has never seen this neomutt bug before,
has no clue where his messages went, and all those messages have been
learned as spam without the user's knowledge.
Here is my rationale for severity grave:
* This is a regression from a previous version.
* The behavior makes no sense as an intentional UI change.
* The bug can cause behaviour of which the user is unaware.
* The unintended behavior caused by this bug can have significantly
detrimental effects that are difficult discover and difficult to undo.
Users of neomutt (and mutt) are typically a different kind of user than
those who stick with Thunderbird or the Gmail web interface. They are
likely to take full advantage of save-hooks and other advanced neomutt
features. They are also more likely to type sequences of commands
quickly and by habit, only looking at the command line at certain
pauses.
The above scenario is not based on a hypothetical setup. I run the
renich.org mail server, which uses spamassassin to score incoming
messages. Messages with scores above a certain threshold are rejected
during the SMTP dialog, but messages with low-positive scores are
accepted. I have a save-hook that uses =spam as the default folder for
messages that spamassassin marks with a low-but-positive spam score. I
do have a spam folder, with behavior similar to what is stated above,
except that the auto-learning happens from a cron job overnight.
While I have not had the above happen to me where the messages were
saved to the spam folder and learned as spam before I caught it, it
could have happened. The way I discovered this bug was, however, very
similar. The actual (but unintended) save target was a different
folder. It took several hours of investigation to determine what the
bug was, where the messages actually went (which was not at all obvious
even after I understood the bug), and to restore the messages to the
intended destination.
Debian Policy does not mention "severity" or "grave" anywhere. The
Developers Reference lists the severities that are considered RC, but
does not define them. The only definitions I can find are at [1]
which states
grave: makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the
accounts of users who use the package.
[1] https://www.debian.org/Bugs/Developer
If you contrast this with "critical" which uses the phrase "serious data
loss", I think it is clear that there are different levels of data loss
(with respect to the bug severities), and messages being moved without
the user's knowledge (a) that they are being moved, and (b) to where
they are being moved, can easily be construed as data loss. The effort
I put into recovering my lost messages was commensurate with restoring
files from a system backup. The fact that the messages were not
"deleted", simply hidden, does not mean that this is not "data loss".
...Marvin
