Subject: Re: tests do not work with gpg 2.1

From: Michael J Gruber <[email-masked]>
Date: Tue, 02 Dec 2014 13:55:31 +0100

Jeff King schrieb am 28.11.2014 um 17:50:
> [updated subject, as this is not specific to the v2.2.0 release at all]
> 
> On Fri, Nov 28, 2014 at 10:48:51AM +0100, Michael J Gruber wrote:
> 
>> Are you running gnome_keyring_deamon by any chance? It think it runs by
>> default in Gnome, claims to offer gpg_agent functionality but does not
>> seem to do so fully. I.e., its presence may keep gpg2.1 from starting
>> its own gpg-agent. But gpg2.1 ("gnupg modern branch") needs a new
>> gpg-agent which knows how to handle secret keys for gpg2.1.
>>
>> (I may take a shot at trying, but I'm on Fedora - they're slow and
>> special in all things gpg/crypto. And compiling gpg2.1 means compiling
>> all the bits and pieces that monster consists of these days...)
> 
> I'm not running the gnome daemon (I do normally run gpg-agent, though),
> and I can reproduce.

You get the passphrase prompt, Steven didn't, if I understood correctly.
You can continue successfully by hitting OK, Steven coudn't hit anything...

> I wanted to try experimenting today with making sure GPG_AGENT_INFO was
> unset in the environment. But despite nothing changing (i.e., before I
> even cleared that variable), I'm getting totally different results.
> 
> Now when I run t4202, I get no agent prompt, and just:
> 
>     ok 40 - dotdot is a parent directory
>     
>     expecting success: 
>             test_when_finished "git reset --hard && git checkout master" &&
>             git checkout -b signed master &&
>             echo foo >foo &&
>             git add foo &&
>             git commit -S -m signed_commit &&
>             git log --graph --show-signature -n1 signed >actual &&
>             grep "^| gpg: Signature made" actual &&
>             grep "^| gpg: Good signature" actual
>     
>     Switched to a new branch 'signed'
>     gpg: skipped "C O Mitter <[email-masked]>": No secret key
>     gpg: signing failed: No secret key
>     error: gpg failed to sign the data
>     fatal: failed to write commit object

That is how things turned for Steven, afaik.

> And then a subsequent run gives me:
> 
>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/19D48118D24877F59C2AE86FEC8C3E90694B2631.key': Permission denied
>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/E0C803F8BC3BCC4990E174E05936A7636E888899.key': Permission denied
>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/FCFAC48BF12AC0FCC32B69AB90AA7B1891382C29.key': Permission denied
>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/D50A866904B91C0C49A3F6059584F4A09807D330.key': Permission denied
>     FATAL: Cannot prepare test area
> 
> It seems that it creates the private-keys directory without the 'x' bit:
> 
>     $ ls -ld trash*/gpghome/private-keys-v1.d
>     drw------- 2 peff peff 4096 Nov 28 11:45 trash directory.t4202-log/gpghome/private-keys-v1.d/
> 
> So that's weird, and doubly so that it is behaving differently than it
> was last night. Obviously _something_ must have change. Maybe something
> related to the state of my running agent, I guess.
> 
> -Peff
> 

I think if you unset GPG_AGENT_INFO, gpg2.1 thinks there is no agent,
starts it's own and talks to it via a socket directly (no env variable).
Now that one seems come with different options (regarding pinentry) so
that it can't even ask you for a passphrase.

That private-keys directory is from the first run of gpg2.1 on a pre-2.1
GPGHOME. It converts the old secring db to that new dir of entries and
uses that instead.

Regarding the umask: That may actually be fallout from

e7f224f (t/lib-gpg: make gpghome files writable, 2014-10-24)

where I didn't expect directories to be present in gpghome. Maybe i
should change

chmod 0700 gpghome
chmod 0600 gpghome/*

to

chmod -R o+w gpghome/

though I felt somehow safer with the explicit permissions.

Michael