#909 Always avoid Enigmail to send out messages it indicates as protected to the user without any protection at all

[Hernani Marques]

After the fatal error in Enigmail/p≡p for Windows (see https://pep.foundation/blog/enigmailpep-current-release-for-windows-is-faulty-solution-in-progress/index.html) it must be ensured by any means that messages go out unprotected / unsigned / unencrypted anytime they are indicated to the user as secure, secure & trusted or signed, encrypted or encrypted & signed if that's -- finally -- not about going to happen.

In the example, it's about the Enigmail/p≡p mode, which after faults in p≡p distribution 1.0.23 resulting in memory errors (which shouldn't occur, but could!), results in messages to be sent out in the clear text.

Perhaps it could help to check if the actual thing which is returned at the very end is signed, encrypted & signed or just encrypted at all (depending on the mode & (user) preferences used).

If that's not the case, for whatever reason, Enigmail (in whichever mode) should inform the user that protection / signing / encryption (wording depending on the mode) cannot be ensured and that the message is about to go out unprotected / unsigned / unencrypted.

Indications to the user in the message should then change to unsecure / unsigned / unencrypted and the user must again press "send". He/She then at least was informed about what's about to happen.

It's certainly not a good idea to stop the user from communicating: that's a p≡p principle, but also generally it's not very helpful as it would be sad if the reaction of the (uninformed) user would be to uninstall the Enigmail addon altogether -- at least in cases it's a temporary error.

[Hernani Marques]

Title was completely bogus before: sorry.

[Claudio Luck]

The minimal design of this protocol depends on a foundamental decision:

(a) is it acceptable to eventually throw away already signed/encrypted messages coming from the engine if they don't math post-flight checks? or

(b) should we rather change the pEp API so that a "want" or "minimal-want" rating can/must be passed, and the engine rejects the request if it can't reach that rating?

(b) is way better as it is explicit on all levels, less inference, but... requires an API change/extension.

We can combine the two strategies for even more failsafety.

[Patrick Brunschwig]

Just to be surewe get this right. Enigmail sends every message to pep, whether that message will be encrypted or not. In other words, the maximum we can do is check if the resulting message from has the same security level as we indicate in the GUI.

[Patrick Brunschwig]

In the case of classical Enigmail this is not an issue because the process is completely different.

[Claudio Luck]

Exactly. The message returned by the adapter should not be sent when the rating is lower than the last prediction shown to the user. In case of this error, the user should be informed, as an exception to our principle of not interrupting the user.

[Claudio Luck]

Correction/Extention: there is no cardinal ordering between no-color and colors. So the decision to display a warning is a sequential expert-system. And we don't define the comparison by numerical values, but by the resulting color mapping.

When the adapter fails/crashes, assume no-color.

If the prediction was red: plan downrating-warning if the rating is no-color
If the prediction was no-color: plan downrating-warning if the rating is red
If the prediction was yellow: plan downrating-warning if the rating is no-color or red
If the prediction was green: plan downrating-warning if the rating is no-color, red or yellow

If the downrating-warning is planned:
Inform user about the degraded rating (set user back to edit window unconditionally)

[Patrick Brunschwig]

same as bug [#946]