Opened 5 years ago

Closed 5 years ago

#7093 closed enhancement (fixed)

Enhance Enigmail preferences in TorBirdy

Reported by: sukhbir Owned by: ioerror
Priority: Medium Milestone:
Component: Applications/TorBirdy Version:
Severity: Keywords:
Cc: tagnaq Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Karsten N. from JonDo has brought the following points to our notice about TorBirdy's Enigmail preferences:

1: You append the hidden keyserver used for Tor to the

"extensions.enigmail.agentAdditionalParam"

Why not using "extensions.enigmail.keyserver" for the keyserver. It may be possible to add more keyserver in a comma separated list if more hidden services are known and and let the user choose one.

Additional the user will see the used keyserver in the dialog and not the default Thunderbird keyserver.

2: You are using the keyserver option "no-auto-key-retrieve".

I did not found this option in my GnuPG documentation, only "auto-key-retrieve" is documented and disabled by default.

I would recommend the usage of "--no-auto-key-locate" for "extensions.enigmail.agentAdditionalParam". It will do the job and avoid web-bug like tracking with OpenGPG keys. For key search only the local keyring is used with this option.

3: I got some returns of TorBirdy user. The option in the preferences dialog:

"Disable GPG '--throw-keyids' [default: enabled]"

is not understandable for some user. May be we can replace it by a more "normal" language string, something like:

"Put the recipient key IDs into OpenPGP encrypted messages (not recommended)"

JonDo is recommending TorBirdy so we have some valuable feedback from that end also. If we agree to these changes, Karsten will send us a patch for them.

Child Tickets

Change History (2)

comment:1 in reply to:  description Changed 5 years ago by ioerror

Replying to sukhbir:

Karsten N. from JonDo has brought the following points to our notice about TorBirdy's Enigmail preferences:

1: You append the hidden keyserver used for Tor to the

"extensions.enigmail.agentAdditionalParam"

Why not using "extensions.enigmail.keyserver" for the keyserver. It may be possible to add more keyserver in a comma separated list if more hidden services are known and and let the user choose one.

Additional the user will see the used keyserver in the dialog and not the default Thunderbird keyserver.

If we find it works identically, I'm fine with changing it. However, I wanted to ensure that we always added it when gpg was called.

2: You are using the keyserver option "no-auto-key-retrieve".

I did not found this option in my GnuPG documentation, only "auto-key-retrieve" is documented and disabled by default.

'no-' is a generic prefix to disable it. Different versions behave differently and so we are explicit rather than implicit.

I would recommend the usage of "--no-auto-key-locate" for "extensions.enigmail.agentAdditionalParam". It will do the job and avoid web-bug like tracking with OpenGPG keys. For key search only the local keyring is used with this option.

That is already taken care of, I believe.

3: I got some returns of TorBirdy user. The option in the preferences dialog:

"Disable GPG '--throw-keyids' [default: enabled]"

is not understandable for some user. May be we can replace it by a more "normal" language string, something like:

"Put the recipient key IDs into OpenPGP encrypted messages (not recommended)"

That seems fine.

JonDo is recommending TorBirdy so we have some valuable feedback from that end also. If we agree to these changes, Karsten will send us a patch for them.

I'm fine with 1 and 3 but 2 is just a weird gpg ism that i think we'd be best not to change.

comment:2 Changed 5 years ago by sukhbir

Resolution: fixed
Status: newclosed
  1. I feel that it is better that we specify the keyserver explicitly, rather than adding it to the list (extensions.enigmail.keyserver). One of the reason is that we are already overriding Enigmail settings by calling gpg with `additionalParam' so if we were to go down the list route, then how do we pick which keyserver will be used? So to prevent unnecessary confusion, let's stick with the current approach and if need be, we will do this later.
  1. Fixed!
Note: See TracTickets for help on using tickets.