Opened 5 years ago

Closed 4 years ago

#9060 closed defect (wontfix)

gpg reads .gnupg/gpg.conf

Reported by: proper Owned by: sukhbir
Priority: Medium Milestone:
Component: Applications/TorBirdy Version:
Severity: Keywords:
Cc: proper, isis@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Gpg used by enigmail will still read ~/.gnupg/gpg.conf.

Not sure if this is what you expect or if this could cause side effects with other (proxy) settings in (old) gpg.conf's.

This was discovered this accidentally, because I disabled throw-keyids in TorBirdy settings and still ended up with mails having this feature enabled, because in my ".gnupg/gpg.conf" the option "throw-keyids" was set.

I don't know if there is any --ignore-config command line option for gpg, if --homedir combined with --no-default-keyring is the only option to prevent this (which would have other side effects as well) or if this whole ticket is a non-issue.

In the latter case, sorry for the noise and feel free to close this ticket as invalid.

Child Tickets

Attachments (1)

9060-avoid-reading-gpgconf.patch (3.2 KB) - added by isis 5 years ago.
output of git commit --patch-with-stat HEAD~1..

Download all attachments as: .zip

Change History (8)

comment:1 Changed 5 years ago by isis

Cc: isis@… added
Status: newneeds_review

There is an "ignore config" command for GnuPG, it´s "--no-options". Although, this can have unwanted effects because GnuPG will then not know where to look for your default keyring, which key to sign with, etc. It will also fall back to the default options (for whichever GnuPG version you´re running) for the personal-{digest,cipher,compress}-prefs options, meaning that if you specified SHA256 as your preferred digest it will go back to being SHA1. Literally, all the options get reset.

If Sukhbir and Jake think it´s a good idea, I´ve added the "--no-options" flag as well as a mechanism for making sure the keyrings are still found, the patch is attached. (Or I can make a pull request if that´s easier, just poke me on IRC.)

Someone should test my code first, and I have a build available and uploaded (ask me where it is on IRC); I don´t have Thunderbird/IceDove.

Changed 5 years ago by isis

output of git commit --patch-with-stat HEAD~1..

comment:2 Changed 4 years ago by sukhbir

Owner: changed from ioerror to sukhbir
Status: needs_reviewaccepted

comment:3 Changed 4 years ago by sukhbir

OK, so given that we are no longer forcing --throw-keyids, let's revisit this ticket.

The command line settings take precedence over the configuration file and I think this works well for us because we are not switching between these preferences anyways. We were doing so just for --throw-keyids but as pointed out, that has also changed. So if the user did have some setting in the configuration file, it will be overwritten by TorBirdy's settings, which is exactly what we want.

The reason adrelanos had this problem when we were forcing --throw-keyids by default was that when --throw-keyids was disabled, we were not setting --no-throw-keyids but instead just removing the argument completely, and therefore the setting from the configuration file was read by GPG (and took precedence over our non-existent setting.) But this is no longer a concern now.

There are no other options which are toggled between the configurations, so I think we are safe to go with the default route. If the need for this arises or you have some other opinion and disagree, I will merge the patch isis submitted.

While I agree with the intention of the ticket, we have followed the idea of "forcing" all settings and not allow them to be overwritten by the user ones; the idea behind "we know better" is also related to that because if we start asking what should the user prefer -- their settings or our settings -- it gets tricky and we had rather live with the latter :)

(I am still open to what you have to say though and will not close the ticket myself.)

comment:4 Changed 4 years ago by proper

What about users who heavily customized their gpg.conf? What other settings in gpg.conf for identity 1 could be problematic if they are used for identity 2 in Thunderbird?

Enigmail in an anonymous mail client reading ~/.gnupg/gpg.conf is something you wouldn't expect. Therefore it shouldn't happen.

comment:5 in reply to:  4 Changed 4 years ago by sukhbir

Replying to proper:

What about users who heavily customized their gpg.conf? What other settings in gpg.conf for identity 1 could be problematic if they are used for identity 2 in Thunderbird?

The TorBirdy settings override gpg.conf. So if you have some setting in gpg.conf that is more secure/less secure that what we consider it to be, it still doesn't matter because our settings take preference and they are considered more secure.

There seem to be no other settings that could be problematic because we are not switching between any of them.

Enigmail in an anonymous mail client reading ~/.gnupg/gpg.conf is something you wouldn't expect. Therefore it shouldn't happen.

It's not exactly Enigmail here, but gpg and this is where the difference is because we do not care for the settings that we are not changing. So if you have a setting X in gpg.conf and so does TorBirdy, we override it with our setting. If you have some setting in gpg.conf that is less secure, again, our setting takes preference. So in the end, it doesn't matter to us what gpg.conf has. It did matter with --throw-keyids, but that has changed.

Like I said, I agree with intention of the ticket. Had there been a GPG switch to do it, I would have probably thought of handling this. But for now, what we are doing should be OK as I have described.

comment:6 Changed 4 years ago by proper

Ok, I understand your point.

My point is still: There are unknown unknowns. Users can go creative changing settings, anything can go wrong, will go wrong and no one knows and what features gnupg may introduce in further releases. It just seems wrong due to the nature of the project to read anything unnecessary from ~/home/*.

Feel free to close this one either way.

comment:7 Changed 4 years ago by sukhbir

Resolution: wontfix
Status: acceptedclosed

Yes, I also understand where you are coming from, but given the options we have, what we are doing now is OK because the alternatives are hack-ish because GPG does not help us with this. Of course this is not a hard-and-fast rule, and if things change, we will revisit this ticket and pick on the patch we have.

Note: See TracTickets for help on using tickets.