gpg-agent out of control!
Environment: * OS X version: (e.g. 10.7.2) 10.7.4 * GPGTools Installer date: 20120318
I just installed GPGTools after long time use of the command like version of GPG. I'm very alarmed by the default behavior of storing pass phrases in memory, and by the lack of documentation and what seems like a bug which prevents me from changing this behavior!
I have some files encrypted with a symmetric cipher. When I viewed them via "gpg -d", I'm prompted by a GUI program, "Pinentry" for the pass phrase. Thereafter, the phrase is stored in memory by gpg-agent, without my consent.
The "Save in Keychain" box in Pinentry is unchecked. There is no obvious way to disable this in the configuration files gpg.conf and gpg-agent.conf. When I found the preferences pane, "Use Keychain to store preferences" was unchecked. As far as I can understand the situation, this preference is being violated. (Moreover, there's no mention of how to configure or disable this Pinentry program.)
Is there a way for an old curmudgeon like me to just have a CLI version of GPG with GPGTools?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Luke Le on 19 Jun, 2012 08:05 PM
Hi Jeremy,
the default behaviour was introduced in gpg 2 if I'm not completely mistaken.
It's smart for new users but I can absolutely understand if long time users have a problem considering the impact on security.
You can however very easily disable this behavior by simply setting the time to cache passphrases to 0 or a very small amount of seconds in GPGPreferences (it should be in your System Preferences app if you've installed the entire GPGTools suite.)
The "Save in Keychain" is a completely different behavior, meaning that the passphrase is actually stored permanently in Apple's Keychain Access application.
The checkbox in the pinentry window is for a single key, the setting in GPG Preferences is applied to every key.
As to your last question if you can return to the terminal way of asking for the passphrase, YES, we've just recently included that.
Please download the nightly version of GPGTools from http://nightly.gpgtools.org and install that version.
After installation, please add the environment variable:
export PINENTRY_USER_DATA="USE_CURSES=1"
into your .bashrc or profile file.
Please let us know if it works
Support Staff 2 Posted by Luke Le on 19 Jun, 2012 08:07 PM
And yeah, we're very aware of the lack of documentation and are trying our best to finally work on it, but unfortunately we're a very small team of 4-5 active people and are working hard on improving our tools in our spare time.
It will take time but it's all on our todo
3 Posted by Jeremy Dolan on 19 Jun, 2012 10:43 PM
Hi Luke. Thanks greatly for the swift and thorough response to a message written in the midst of frustration!
Allow me to make a friendly UI suggestion. I think I now understand the difference between "Use keychain to store passphrases" and "remember passphrases for x seconds" controls. The fact that these are right next to one another in the preference pane, however, is absolutely certain to cause much confusion. By default, it even looks as if the later is greyed out and not available when the former is unchecked. The input box for the amount of seconds is greyed out with the value 600, which is—in actuality—indicating the default, active, value, but which—intuitively—looks like an unchangable parameter for an inactive feature. Annotated screenshot attached to illustrate the problem and suggest a couple of slight improvements.
I see now a lot of the issues I have are a gpg1 v gpg2 thing. (e.g., gpg-agent is required by gpg2, whereas I'd quite like to have as little to do with it as possible). I see in a screenshot GPGTools used to install both versions; is there any official reason why gpg1 no longer comes in the installer? Will I run into issues if I install the latest gpg1 myself, along-side GPGTools?
Support Staff 4 Posted by Luke Le on 19 Jun, 2012 10:52 PM
Hi Jeremy,
thanks for the UI suggestions! The preference pane is indeed not clear at all and we'll rework it entirely and probably will introduce "section headers" like the "General Options" to separate it. Also as you mentioned the default comment is useless and should be handled better. Already having to set seconds doesn't make sense except if you want to set it to 0. Maybe we'll replace it with a select box with an option "Don't remember passphrases".
As to the gpg2 vs. gpg1 question, basically gpg1 is obsoleted and from what I've learned working with gpg it's mostly due to implementation details, where the goal set for 2.x was to make it more modular, dependent on other libraries as to better separate the code.
The one advantage for the user sure is the gpg-agent and for some advanced users, that it supports handling S/MIME as well.
You should still be able to install gpg1 (we default to gpg2 though since that's the version which is actively mantained. development for gpg1 stopped unless for critical fixes, if I'm not mistaken) using the GPGTools installer. If that's not available you can still get the most current version from http://nightly.gpgtools.org
It should also work to simply compile it yourself or using macports, brew, or any of the other systems but I can't think of any reason why you should prefer that over using our MacGPG1 installer.
What's your biggest problem now that you're old workflow should be pretty much restored with the changes highlighted earlier?
5 Posted by Jeremy Dolan on 19 Jun, 2012 11:20 PM
My understanding (and it's totally possible that I'm wrong, or out of date) of the gpg1/gpg2 split wasn't that gpg1 was being phrased out, but that it would be maintained in parallel as a standalone, non-modular, CLI version. And I've understood the lack of recent gpg1 updates as evidence of its perfection, rather than its obsolescence. :)
As for gpg-agent, it's not so much a change of workflow at issue. If anything, I downloaded GPGTools in the hopes of a new, improved workflow, at least vis-a-vis Mail.app integration. The main issue is one of paranoia, I suppose. In short, the thought of a simple "gpg -d" command passing my passphrase from a modularized gpg2 and GUI-fied Pinentry, through a UNIX file socket, to a Mac port of a passphrase caching daemon where it will be considered for medium-term storage fills me with unimaginable terror.
Support Staff 6 Posted by Luke Le on 19 Jun, 2012 11:30 PM
I think your understanding actually describes it better :)
Saying it's obsolete is completely not true, it was only meant to say actually that it's no longer actively developed, which indeed is a very different thing.
I can absolutely understand your problem with the gpg-agent as "man in the middle". Trusting the developer of gpg I hope he's making sure in one way or another that the cached passphrases are very hard to access, but nothing is impossible of course. Setting the cache time to 0 helps the issue but doesn't solve it entirely. So you may as well be better off with GPG 1.
Out of curiosity, did you manage to get the curses based pinentry version work for you with the described evironment variable?
Also, we've completely rewritten GPGMail from scratch focusing completely on usability and seamless integration into the Mail.app UI. It removes a lot of settings of the old plugin which will return over time as default Terminal commands for advanced preferences and only those affecting non-power users as visual preferences which hopefully will help to attract new users and introduce them to secure communication.
I'm curious to hear your thoughts in regards to our GPGMail UI changes.
7 Posted by Jeremy Dolan on 19 Jun, 2012 11:50 PM
I haven't tried the nightly GPGTools yet. But I did install the nightly version of GPG1. One thing perhaps worth noting: the gpg.conf file put in place by the latest GPGTools is incompatible with the nightly GPG1 package, and GPG1 will refuse to run with it.
E.g., when running gpg -d:
% gpg -d [file] gpg: [home]/.gnupg/gpg.conf:233: invalid auto-key-locate list
%
(the offending line: auto-key-locate cert pka ldap hkp://keys.gnupg.net)
I wish you all the best of luck with the revised mail integration. No one's managed to really get PGP out there, for the last 15 years. The tutorials and all that you have up on the site look promising. If I have a chance, I'll try to install the full Tools from trunk and see if I can offer any useful feedback.
Support Staff 8 Posted by Luke Le on 19 Jun, 2012 11:56 PM
Oh yeah, this is a known bug. We haven't really figured out the reason since it's not always that line that fails.
Simply remove cert and pka from the values list and you should be fine, unless you did that already.
I think with the amount of privacy related issues introduced by social networks and new data storage rules for the internet this is a good time for our type of tools. I'm excited to see how they catch on.
Steve closed this discussion on 10 Jul, 2012 10:54 AM.