Bug #9422

Consider disabling key management feature of Enigmail

Added by sajolida 2015-05-18 11:56:30 . Updated 2016-01-02 03:43:29 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Start date:
2015-05-18
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:
268

Description

We prefer providing a single tool for a single task, unless we have a good reason to do so. With the return of Icedove (Feature #5663) we will add Enigmail.

  • Is it possible to disable its key management features?
  • Do we want to do that?

Subtasks


Related issues

Related to Tails - Feature #5663: Return to Icedove Resolved 2013-10-16
Related to Tails - Bug #9404: Document how to generate strong OpenPGP keys with Seahorse instead of Claws Mail Resolved 2015-05-14

History

#1 Updated by sajolida 2015-05-18 11:56:51

#2 Updated by sajolida 2015-05-18 11:57:01

  • related to Bug #9404: Document how to generate strong OpenPGP keys with Seahorse instead of Claws Mail added

#3 Updated by sajolida 2015-05-18 11:59:27

I’ve never really used it myself and should train myself to use Seahorse more systematically to see if it’s good enough.

I don’t think this ticket is a blocking Feature #5663 and I think it’s low priority (until having this feature of Enigmail is a problem, for example for frontdesk).

#4 Updated by intrigeri 2015-05-18 15:05:30

> I don’t think this ticket is a blocking Feature #5663

Well, if we don’t block Feature #5663 on this ticket at all, then it implicitly means that we consider it’s fine to ship Enigmail’s key management GUI, at least for a while… which is IMO exactly the discussion we should have here.

> and I think it’s low priority (until having this feature of Enigmail is a problem, for example for frontdesk).

IMO it’s always a UX problem to ship two different pieces of software that basically do the same thing, and that’s why we generally try hard to avoid that. I’m sure we already agree on that general policy anyway :)

Bonus technical info: in the specific case at hand, if we enable Enigmail’s key management GUI, then we’ll have to make sure it is configured in a way that’s similar to Seahorse (or better if we can). E.g. keyservers (IIRC Enigmail basically overrides the settings configured in gpg.conf) and default key length come to mind first. This work might take as much time as disabling that key management feature, to be checked.

Also, the blueprint currently says that “Enigmail has a much easier guide for generating a key and setting up GnuPG. The guide starts pretty much automatically and is very informative.” (I guess it’s compared to Claws Mail?) This might be a good reason to include this feature despite the aforementioned drawbacks.

#5 Updated by intrigeri 2015-08-28 01:34:02

  • Assignee set to kytv
  • Target version set to 246
  • Type of work changed from Discuss to Research
  • Deliverable for set to 268

It seems that we first need someone to compare Enigmail’s key management with Seahorse, before we can discuss this topic efficiently => assigning to kytv, who’s in charge of the integration part of Feature #5663 (and setting metadata accordingly).

#6 Updated by kytv 2015-09-28 05:46:06

One data point: in all the time that I’ve used Enigmail (and other methods) to refresh/retrieve keys over Tor I’ve never had a crash. Seahorse on the other hand…

Sometimes when syncing keys the Seahorse window will just disappear with a segfault (Bug #9970).

After ~9 months of working on the test suite and seeing these crashes I’m not a fan of Seahorse. :/

#7 Updated by intrigeri 2015-10-03 04:14:35

> Sometimes when syncing keys the Seahorse window will just disappear with a segfault (Bug #9970).

It might be that this has been fixed in Jessie, and we won’t know before I’ve fixed Bug #9792.

#8 Updated by sajolida 2015-11-27 04:47:16

  • Target version changed from 246 to Tails_2.0

#9 Updated by intrigeri 2015-12-19 10:18:13

kytv, this is an important change if we decide to do it, that should IMO go into 2.0~rc1, and might take some development time. With all this in mind, status / ETA?

#10 Updated by intrigeri 2015-12-19 10:19:05

  • Priority changed from Normal to Elevated

#11 Updated by kytv 2015-12-20 06:56:07

  • Status changed from Confirmed to In Progress
  • Assignee changed from kytv to intrigeri
  • QA Check set to Info Needed

The Key and SmartCard management features are hidden from the menus in my local branch.

If you agree with me that hiding the options within the menus would be an acceptable way to disable this feature, I can have it ready for review (with tests) quickly.

#12 Updated by kytv 2015-12-20 09:46:33

  • % Done changed from 0 to 30
  • Feature Branch set to kytv/feature/9422-disable-enigmail_key_mnmt

So…if disabling it from the menu is OK, the included branch will do just that.

(Optimistically bumping the percentage done)

#13 Updated by intrigeri 2015-12-20 10:09:22

  • Assignee changed from intrigeri to kytv

kytv wrote:
> If you agree with me that hiding the options within the menus would be an acceptable way to disable this feature, I can have it ready for review (with tests) quickly.

I’d prefer if you discussed this with your team-mates, unless it’s about something that I know something you folks don’t :)

#14 Updated by kytv 2015-12-22 13:08:43

intrigeri wrote:

> I’d prefer if you discussed this with your team-mates, unless it’s about something that I know something you folks don’t :)

All good. :)

Email sent to the ML.

#15 Updated by Anonymous 2015-12-30 04:47:09

I’d rather not disable this feature. Sometimes, when there are missing keys for any recipient, Icedove/Enigmail will show a window telling you this. This window has buttons to access the key management feature. It seems weird to hide this if a user wants to access this again, at a later point in time.

I also agree with kytv’s remark on the ML that people who used Enigmail with Windows or Mac OS before might feel lost if they do not have access here.

I am aware that this adds a lot of documentation work, but I feel that that’s not a valid reason to disable this.

#16 Updated by Anonymous 2015-12-30 05:40:12

  • Status changed from In Progress to Rejected

Discussed in a meeting and we mostly agree that it’s better to keep it.
Closing.

#17 Updated by kytv 2015-12-30 06:11:49

  • % Done changed from 30 to 0
  • QA Check deleted (Info Needed)
  • Feature Branch deleted (kytv/feature/9422-disable-enigmail_key_mnmt)

#18 Updated by kytv 2015-12-30 06:12:03

  • Assignee deleted (kytv)

#19 Updated by intrigeri 2016-01-02 03:43:29

  • Status changed from Rejected to Resolved

It has been “considered” :)