After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681706 - implement per contact settings for crypto and receiving
implement per contact settings for crypto and receiving
Status: RESOLVED WONTFIX
Product: evolution
Classification: Applications
Component: Mailer
3.4.x (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[wontfix?]
Depends on:
Blocks:
 
 
Reported: 2012-08-12 19:53 UTC by Christoph Anton Mitterer
Modified: 2012-10-18 04:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christoph Anton Mitterer 2012-08-12 19:53:27 UTC
This is from #681691 which was closed for whatever reasons...


Hi.

Long missing features to make Evolution an at least somewhat professionally 
usable MUA would be per-contact (be it a person or a ML) settings at least for
the following:


What kind of encryption/signing to expect from a given contact:
Right now, Evolution just shows whether a mail was correctly verified or not,
or whether no signature was in place at all (by showing nothing).
It should be possible to specify what to expect from a given contact, like,
expect mails to be encrypted and/or signed with OpenPGP and/or SMIME.
If such a constraint is not meet, the mail should at best not be shown at
all... just via some "yes please show, I know what I'm doing button),.. or the
background should be all red.
The current way of showing this (small box at the end of the mail) is not good
enough visible.
All this is especially important when dealing with really a lot of mails and
contacts.
It's really impossible to correctly remember to check (and to remember what to
expect) for each mail manually.


Cheers,
Chris.


btw: Whenever I said "contact", it should be configurable per "object in the
address book" (applying for all it's configured email addresses)... but also be
overridable for selective email addresses for a given object.
E.g. I have two addresses from a person, one home, one work email.
It's totally valid, that one may never expect encrypted mails from work, but
always from home.... and also to have different languages at both, etc. pp.
Comment 1 André Klapper 2012-08-13 14:34:05 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 204029 ***
Comment 2 André Klapper 2012-08-13 14:35:53 UTC
Whoops, sorry.
Comment 3 André Klapper 2012-08-13 14:37:33 UTC
Sounds like a rather uncommon usecase and like lots of manual work. 
Proposing WONTFIX.
Comment 4 Christoph Anton Mitterer 2012-08-13 18:58:15 UTC
Uhm why? Uncommon...??

It's actually MOST command that not all of your contacts have crypto or send you signed/encrypted mails... and right now, as I laid out, it's basically impossible to keep track on where one expect encrypted and/or signed mails and where not, thereby making the whole cryto thingy rather useless.


Conceptually this is similar to downgrade attacks... making a less secured (in this case no crypto at all) forged message, hoping that the recipient doesn't recognise that he should have received something of higher security (i.e. signed and/or encrypted).

The same problem is what browsers and SSL/TLS suffer from, that no-one usually knows where he can expect SSL/TLS, and that no-one warns you if you don't get it.
The "famous" HTTPS Everywhere plugin tries to deal with that problem a bit.



Therefore IMHO, sureley not WONTFIX... actually (and I guess I really have some decent knowledge on cryptography and security)... I'd consider this one of the most important features (with respect to cryptography).
Comment 5 André Klapper 2012-08-13 19:40:04 UTC
(In reply to comment #4)
> It's actually MOST command that not all of your contacts have crypto or send
> you signed/encrypted mails... and right now, as I laid out, it's basically
> impossible to keep track on where one expect encrypted and/or signed mails and
> where not, thereby making the whole cryto thingy rather useless.

The question is, how many people care about those expectations.
I don't consider it common that people want to manually add info for all of their contacts whether they normally send signed/encrypted emails or not.

> The same problem is what browsers and SSL/TLS suffer from, that no-one usually
> knows where he can expect SSL/TLS, and that no-one warns you if you don't get
> it.

> Therefore IMHO, sureley not WONTFIX...

Patches welcome, as the Evolution team is quite small (which also influences WONTFIX).
Comment 6 Christoph Anton Mitterer 2012-08-13 19:52:25 UTC
> The question is, how many people care about those expectations.
Don't get me wrong (or offensive)... but that's just the GNOME philosophy problem...
I guess everyone remembers Linus' quote... if you make software for dumb users,... you'll mainly get dumb users...


And still WONTFIX is IMHO the wrong way than... rather keeping it open.
Comment 7 André Klapper 2012-08-13 20:12:36 UTC
I wouldn't call prioritizations based on "there's maybe 0.1% of users that care about this feature and maybe 2.5 developers to write and maintain this feature" a "philosophy" but rather common sense, and WONTFIX is just an honest answer. 
It does not mean that contributed patches would not be accepted. It means to not expect maintainers to write and maintain code that a small portion of users will ever use.
Comment 8 Christoph Anton Mitterer 2012-08-24 00:14:52 UTC
Hi.

Well of course anyone can write patches ... but that means a lot of work digging into the Evolution code which (to be honest) I haven't had planned.


When it comes to "how much users care?"... well sure, you may be right that the average user doesn't care at all.
But the average also doesn't care about security at all; neither encryption nor signing; but still, you don't remove these features, do you?


So I interpret this as a stance, that Evolution wants to implement and support signature/verification in a secure and sane way.


Now I don't claim the actual encrypting/signing code itself would be wrong, but to get real reasonable security on needs to deal with issues (and attacks) on much higher levels.
These includes funny attacks like "downgrade attacks".
To some extent one can hope that the crypto backend deals with many such things already out of the box, but not to all.

And this is just one such issue:
If there is now way to tell, that you expect signed and/or encrypted from a contact, you open a broad field of meta (or "social") attacks, most notably, that and attacker sends an plain email, and the reader just forgets to check whether the green "verified" bar is shown.


As I tried to explain above, the same issue is present with https, and there people really start to get into troubles with this (why things like "HTTPS Everywhere" come up).


Now I don't want to show off, but I guess I have some decent knowledge on crypt and security (well at least I sat physically in countless such lectures at university ^^)... and if you want to give your users encryption/signing; you should also give them the subject of this ticket.
Especially because the social attacks allowed otherwise are the most simple and in many cases effective ones an attacker can do.

If you add functionally that the user is pro-actively asked about what should be expected when new contacts are created, or even defaulting to expect encrypted/verified... you even improve things from a security point of view and positively teach your users.


So to some extent I had hoped that Evolution has kind of a roadmap, where important things (even when nobody really likes them) get onto.


Yeah well, I guess (from my side) we've discussed already all aspects about this issue and how it would be solved (conceptionally).
If there are 2.5 developers around who could be interested, please ask them :)
At least I won't have time in the next few months to get deeper into even more open source projects, even though I'd like too contribute to Evolution.
Now obviously you can close it as wontfix (which is wrong IMHO, as there IS a way to fix this), but then a good idea obviously gets lost; leave it open and others would have a chance to pick this up later on.


Chris.
Comment 9 Matthew Barnes 2012-10-18 04:55:05 UTC
(In reply to comment #3)
> Sounds like a rather uncommon usecase and like lots of manual work. 
> Proposing WONTFIX.

Agreed.