You are not logged in.
Something has been updated that prevents my setup from remembering my password and requiring me to enter it every time I go to sign a file. For example:
% gpg --detach-sign --local-user 5EE46C4C foo.bar
In the past, that command would go through without prompt for a password. Now I get a GUI popup requesting my password. This makes scripting a package signing impossible. Is this a known issue and is there a work-around? Seemed to happen on one of the gnupg updates.
EDIT: Found this thread and the wiki-link therein that solves this.
Last edited by graysky (2014-12-07 13:10:48)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Grrr... I thought that the solution was to create ~/.gnupg/gpg-agent.conf which contains a single line `allow-loopback-pinentry` but found that it is inconsistent. 10 times in a row, the detach-sign operation worked without prompting me for a password, but on the 11th try, it did stop and prompt me through pinentry again. WTF?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Have you tried setting a higher TTL in the ~/.gnupg/gpg-agent.conf? Default is 600s.
default-cache-ttl 86400
Offline
Didn't know about that setting.. I will try it. Guess the question is how to make it indefinite. Under the older version, I never had to enter the password aside from initially. Since I am calling this signing feature from a shell script via a cronjob, asking me once is bad.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Looks like -1 means infinite:
http://git.gnupg.org/cgi-bin/gitweb.cgi … b=HEAD#l54
54 typedef struct cache_item_s *ITEM;
55 struct cache_item_s {
56 ITEM next;
57 time_t created;
58 time_t accessed;
59 int ttl; /* max. lifetime given in seconds, -1 one means infinite */
60 struct secret_data_s *pw;
61 cache_mode_t cache_mode;
62 char key[1];
63 };
You might also set "max-cache-ttle -1" in gpg-agent.conf as well to cover both the per-item cache and the global housekeeping cache timeouts:
http://git.gnupg.org/cgi-bin/gitweb.cgi … =HEAD#l213
It looks like the per-item is swept first, then the max swept without regards to the per-item.
Offline
@TE - Setting either item alone breaks gpg:
% gpg --detach-sign --local-user 5EE46C4C md5sums.txt
gpg: can't connect to the agent: IPC connect call failed
gpg: skipped "5EE46C4C": No secret key
gpg: signing failed: No secret key
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
...even setting the time out to 24 hours does not change for me. It seems to be on the order of 15 min or so where I am prompted for my password in order to continue.
% cat ~/.gnupg/gpg-agent.conf
allow-loopback-pinentry
default-cache-ttl 86000
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
At this point I'd enable debugging in your gpg-agent.conf - looks like there's a specific flag for cache debug as well, see if that provides anything useful. Do a 'man gpg-agent' and they're listed under --debug-level and --debug; I'd assume something like:
log-file /tmp/gpg_debug.log
debug-level 8 # "guru"
debug 0x01000000 # 6 (64) caching
There's also a 'debug-all' listed in the man page if you want to cut to the chase and log every last thing...
Offline
Thanks for the suggestion, TE. I just modified my code to do the signing when I am physically at the keyboard. I might revisit when I have more time.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
At least you can use it with timeout. I can’t use it at all. All programs that want to use the keys complain about a wrong passphare being returned.
According to research I added pinentry-mode loopback to my ~/.gnupg/gpg.conf and allow-loopback-pinentry to my ~/.gnupg/gpg-agent.conf.
Now all applications just fail directly instead of first asking for a passphrase (that does not exist) and fail then.
Why is GPG so unusable?
Offline
...even setting the time out to 24 hours does not change for me. It seems to be on the order of 15 min or so where I am prompted for my password in order to continue.
% cat ~/.gnupg/gpg-agent.conf allow-loopback-pinentry default-cache-ttl 86000
i also sign all my packages (rebuilding everything from source to get advantage of CPU optimizations), but for me, this workaround does work, and that damn thing really keeps cached passphrase for 24 hours and does not ask it again.
default-cache-ttl 129600
max-cache-ttl 129600
allow-preset-passphrase
allow-loopback-pinentry
pinentry-program /usr/bin/pinentry-curses
perhaps allow-preset-passphrase makes the difference?
— love is the law, love under wheel, — said aleister crowley and typed in his terminal:
usermod -a -G wheel love
Offline
[…] and that damn thing really keeps cached passphrase for 24 hours and does not ask it again.
What if one never set a passphrase? Is there an option to simply get the old behavior back?
Offline
What if one never set a passphrase? Is there an option to simply get the old behavior back?
when things worked as we expected, running /usr/lib/gnupg/gpg-preset-passphrase KEYGRIP read then the passphrase for the specified key from stdin and kept it cached for the time specified in max-cache-ttl.
i used that for unattednded package signing before 2.1.
currently it's either broken or possible with some very obscure setup that no one still have discovered.
Last edited by chaonaut (2014-12-27 11:09:08)
— love is the law, love under wheel, — said aleister crowley and typed in his terminal:
usermod -a -G wheel love
Offline
What if one never set a passphrase? Is there an option to simply get the old behavior back?
When looking at the source code of gpg-preset-passphrase, line 147 ("FIXME"), it seems like it can't handle empty passphrases right now. But maybe you could use a "dummy" passphrase and unlock the key at login. I'll post my setup using secret-tool and Gnome keyring, but you can simply replace the secret-tool with echo if you like.
~/.gnupg/gpg-agent.conf (where default-cache-ttl is probably not necessary):
allow-preset-passphrase
default-cache-ttl 300
max-cache-ttl 999999
Restart / kill gpg-agent after changing the configuration and get the fingerprint and keygrip of your keys:
gpg --fingerprint --fingerprint --with-keygrip <your key> # yes, two times --fingerprint (for subkeys)
With these run / put in a login script:
# make sure the gpg-agent is running
gpg-connect-agent /bye
secret-tool lookup keyid "$keyid" | /usr/lib/gnupg/gpg-preset-passphrase --preset "$keygrip" # repeat for all (sub)keys
This way you should never be asked for entering a passphrase. I hope it helps.
when things worked as we expected, running /usr/lib/gnupg/gpg-preset-passphrase KEYGRIP read then the passphrase for the specified key from stdin and kept it cached for the time specified in max-cache-ttl.
i used that for unattednded package signing before 2.1.
currently it's either broken or possible with some very obscure setup that no one still have discovered.
@chaonaut: I'm not sure: Did I discover this "obscure setup" or am I missing something? What you describe sounds pretty similar to what I use.
Anybody looking for some more information might want to see gpg-preset-passphrase and mail about "What's a keygrip?"
Edit: Just found a mail on arch-dev-public regarding passwordless usage of pacman's local key. It requires generating a new key, but in case anyone is interested, have a look at the pacman-key source, especially the %no-protection part. --batch is documented here.
Last edited by Sandwich maker (2014-12-30 06:06:40)
Offline