Hi, either I'm blind or it is not deemed necessary to pick a specific subkey, but I need to :(. I thought enigmail would respect the settings in .gnupg/gpg.conf (in this case default-key) or at least provide a possibility to change the default behavior. I have created additional subkeys, which I exported to my yubikey. Since then, enigmail always fails to sign/encrypt mails, because it always defaults on the most recently created subkeys. Is there any way to override this (I want to use my normal subkeys by default and only if I wanted to switch to the yubikey keys)?
In the following bugreport: https://sourceforge.net/p/enigmail/bugs/256/ somebody asked for this for encryption, and mentions that this is supported by enigmail for signing, but I can't find the mentioned setting :(. Was this removed with 1.7 or something?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is not foreseen that you pick a specific subkey in Enigmail, you can only select the secret key as such. This is done in Account Settings > OpenPGP Security.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know that. Unfortunately, enigmail is useless with my setup. Although, not all hope is lost. Actually, it does work, by forcefeeding a subkey (exclamation mark notation -> 0x1234abcd!) via the config editor / prefs.js. Only thing that doesn't work after that is sending encrypted mails to yourself. But I can live with that. It would be really nice if this could be implemeneted officially. I checked how gnupg is invoked in the background. It uses the --encrypt-to argument, in case you send yourself mails. I don't know why enigmail does this, but it actually isn't necessary. This should also be implemented for encryption (picking a subkey). The reason why this works in my case is that it picks the right encryption key, but the wrong signing key. If I had gnupg setup in a way that it knows I have an encryption key on my yubikey, this workaround would not work. I really believe this issue should be addressed, since it is a fundamential feature of gnupg.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Enigmail does not try to expose all possible features to end users. The goal of Enigmail is to be usable for everyone, including beginners. I think that the concept of subkeys is way too complex even for many average users. Most of them are already confused by public and secret keys.
You can use gpg.conf to configure the way you want to use subkeys. I will not implement specific features for this in Enigmail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can use gpg.conf to configure the way you want to use subkeys. I will not implement specific features for this in Enigmail.
Unfortunately, this doesn't work in this case. gpg is invoked by enigmail with the -u / --local-user argument, completely overriding my settings in gpg.conf. If you / enigmail invoked it with the --default-key argument, it would be a different story. But it does not. Read the gpg manual:
--default-key name
Use name as the default key to sign with. If this option is not used, the default key is the first key found in the secret keyring. Note
that -u or --local-user overrides this option.
-u Use name as the key to sign with. Note that this option overrides --default-key.
If you would change the next enigmail update to use the --default-key argument instead of the -u argument, it would really help.
EDIT:
Ok, patched enigmail myself. It works as expected with --default-key instead of -u.
Last edit: iceman 2014-11-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Iceman or @Sachin Garg:
Can you please tell my how you have patched EnigMail?
Thank you very much!
Some Background information:
The thing is, for mail clients(Enigmail and R2Mail2 on android), I use only one specifc subkey- for only a specific purpose: That one subkey is only used for mail signing.
The other subkeys are used for other purposes: E.g. signing commits in our repositories.
I definitely do not want, that Enigmail uses my git repo sub signing keys for mail signing.
For me, the main secret key is(/should) not(/be) available on those daily used devices ("#sec") and is stored offline. I can easily revoke the subkey of the comprimised device (keylogger, malware etc...), and the main- and other subkeys are unaffected.
Currently, I forced Enigmail using the specific signing/encryption subkey, by removing all other subkeys and main secret key. The other subkeys (commit signing) are used in a seperate virtual machine. See also https://wiki.debian.org/Subkeys
I am used to this workflow many years
svargh
Last edit: svargh 2016-10-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bump. Any response to my pull request, please? At least tell me so if you don't want to merge my pull request (whatever the reason), but at least tell me so that I will start maintaining my own fork, or jump the sinking ship (which is more realistic, if you think there is no reason to fix the current behavior).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have decided that I will not replace "-u" (or the equivalent "--local-user") by "--default-key" in Enigmail. Here is why:
If a user specified local-user in gpg.conf, then use of "-u" in Enigmail will lead to the key being signed by both keys. This is what some users (especially companies) want, expect from Enigmail, and know that it's been supported for the last 10 years. Using --default-key will break this; in other words, gpg.conf will "win" over Enigmail.
The requirement to a specific subkey for signing is by far less common, and average users don't need to do this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If a user specified local-user in gpg.conf, then use of "-u" ...
If a user specified in the gpg.conf local-user/default-key, he understands how gpg works, and I would assume he would expect all user interfaces working on top gpg, to honor this setting, or offer an optional override option in the gui, not default, f*** the settings the user wanted in the gpg.conf
Using --default-key will break this; in other words, gpg.conf will "win" over Enigmail.
Which is the entire point of -u. That optionally, enigmail can be overidden.
Or how about a simple checkbox, something around... "Honor the gpg.conf" (which can be located in the expert settings, default disabled). No behaviour changed, and as option to those that think that enigmail should do what gpg says, not the other way around.
Last edit: iceman 2014-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, following good GPG practices, my main key can't sign or encrypt: it's only for authentication and certification purposes. Then, one subkey is for signing, and another for encrypting.
None of these 3 keys have expired, nevertheless Enigmail fails to sign e-mails, as of recently. It says my main key is not found or is invalid.
It's also worth noting that all 3 subkeys (main: auth and cert, sub1 sign, sub2 encr) are 8192-strong.
Any recent changes in Enigmail that could have triggered this?
EDIT: I saved my e-mail in a draft, closed the window and restarted Thunderbird. Now it worked. Previously, Thunderbird was not open, I had clicked a link to send an e-mail and only the window for that e-mail was open. Maybe Enigmail fails to function properly when this is the case?
EDIT2: I can confirm it, I've reproduced it with a different recipient. Enigmail won't work if Thunderbird is not "totally" open -that is, when only a Thunderbird window to send an e-mail is open, typically this happens when clicking an e-mail address link with Thunderbird off.
EDIT3: the e-mails get sent signed by the main key, not the subkey for signing. I'm with iceman on his request.
Last edit: Israel Planagumà 2015-11-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, either I'm blind or it is not deemed necessary to pick a specific subkey, but I need to :(. I thought enigmail would respect the settings in .gnupg/gpg.conf (in this case default-key) or at least provide a possibility to change the default behavior. I have created additional subkeys, which I exported to my yubikey. Since then, enigmail always fails to sign/encrypt mails, because it always defaults on the most recently created subkeys. Is there any way to override this (I want to use my normal subkeys by default and only if I wanted to switch to the yubikey keys)?
In the following bugreport: https://sourceforge.net/p/enigmail/bugs/256/ somebody asked for this for encryption, and mentions that this is supported by enigmail for signing, but I can't find the mentioned setting :(. Was this removed with 1.7 or something?
It is not foreseen that you pick a specific subkey in Enigmail, you can only select the secret key as such. This is done in Account Settings > OpenPGP Security.
I know that. Unfortunately, enigmail is useless with my setup. Although, not all hope is lost. Actually, it does work, by forcefeeding a subkey (exclamation mark notation -> 0x1234abcd!) via the config editor / prefs.js. Only thing that doesn't work after that is sending encrypted mails to yourself. But I can live with that. It would be really nice if this could be implemeneted officially. I checked how gnupg is invoked in the background. It uses the --encrypt-to argument, in case you send yourself mails. I don't know why enigmail does this, but it actually isn't necessary. This should also be implemented for encryption (picking a subkey). The reason why this works in my case is that it picks the right encryption key, but the wrong signing key. If I had gnupg setup in a way that it knows I have an encryption key on my yubikey, this workaround would not work. I really believe this issue should be addressed, since it is a fundamential feature of gnupg.
Enigmail does not try to expose all possible features to end users. The goal of Enigmail is to be usable for everyone, including beginners. I think that the concept of subkeys is way too complex even for many average users. Most of them are already confused by public and secret keys.
You can use gpg.conf to configure the way you want to use subkeys. I will not implement specific features for this in Enigmail.
Unfortunately, this doesn't work in this case. gpg is invoked by enigmail with the -u / --local-user argument, completely overriding my settings in gpg.conf. If you / enigmail invoked it with the --default-key argument, it would be a different story. But it does not. Read the gpg manual:
If you would change the next enigmail update to use the --default-key argument instead of the -u argument, it would really help.
EDIT:
Ok, patched enigmail myself. It works as expected with --default-key instead of -u.
Last edit: iceman 2014-11-10
Can you tell me the file where you patched this? And what changes were made. Will build my own version ...
@Iceman or @Sachin Garg:
Can you please tell my how you have patched EnigMail?
Thank you very much!
Some Background information:
The thing is, for mail clients(Enigmail and R2Mail2 on android), I use only one specifc subkey- for only a specific purpose: That one subkey is only used for mail signing.
The other subkeys are used for other purposes: E.g. signing commits in our repositories.
I definitely do not want, that Enigmail uses my git repo sub signing keys for mail signing.
For me, the main secret key is(/should) not(/be) available on those daily used devices ("#sec") and is stored offline. I can easily revoke the subkey of the comprimised device (keylogger, malware etc...), and the main- and other subkeys are unaffected.
Currently, I forced Enigmail using the specific signing/encryption subkey, by removing all other subkeys and main secret key. The other subkeys (commit signing) are used in a seperate virtual machine. See also https://wiki.debian.org/Subkeys
I am used to this workflow many years
svargh
Last edit: svargh 2016-10-30
Bump. Any response to my pull request, please? At least tell me so if you don't want to merge my pull request (whatever the reason), but at least tell me so that I will start maintaining my own fork, or jump the sinking ship (which is more realistic, if you think there is no reason to fix the current behavior).
I did not yet have time to look at it; it's still on my (long) todo list.
Ok, thanks. Didn't ask for more. Just for some kind of acknowledgement.
I have decided that I will not replace "-u" (or the equivalent "--local-user") by "--default-key" in Enigmail. Here is why:
If a user specified local-user in gpg.conf, then use of "-u" in Enigmail will lead to the key being signed by both keys. This is what some users (especially companies) want, expect from Enigmail, and know that it's been supported for the last 10 years. Using --default-key will break this; in other words, gpg.conf will "win" over Enigmail.
The requirement to a specific subkey for signing is by far less common, and average users don't need to do this.
If a user specified in the gpg.conf local-user/default-key, he understands how gpg works, and I would assume he would expect all user interfaces working on top gpg, to honor this setting, or offer an optional override option in the gui, not default, f*** the settings the user wanted in the gpg.conf
Which is the entire point of -u. That optionally, enigmail can be overidden.
Or how about a simple checkbox, something around... "Honor the gpg.conf" (which can be located in the expert settings, default disabled). No behaviour changed, and as option to those that think that enigmail should do what gpg says, not the other way around.
Last edit: iceman 2014-11-24
Well, following good GPG practices, my main key can't sign or encrypt: it's only for authentication and certification purposes. Then, one subkey is for signing, and another for encrypting.
None of these 3 keys have expired, nevertheless Enigmail fails to sign e-mails, as of recently. It says my main key is not found or is invalid.
It's also worth noting that all 3 subkeys (main: auth and cert, sub1 sign, sub2 encr) are 8192-strong.
Any recent changes in Enigmail that could have triggered this?
EDIT: I saved my e-mail in a draft, closed the window and restarted Thunderbird. Now it worked. Previously, Thunderbird was not open, I had clicked a link to send an e-mail and only the window for that e-mail was open. Maybe Enigmail fails to function properly when this is the case?
EDIT2: I can confirm it, I've reproduced it with a different recipient. Enigmail won't work if Thunderbird is not "totally" open -that is, when only a Thunderbird window to send an e-mail is open, typically this happens when clicking an e-mail address link with Thunderbird off.
EDIT3: the e-mails get sent signed by the main key, not the subkey for signing. I'm with iceman on his request.
Last edit: Israel Planagumà 2015-11-13