[pkg-gnupg-maint] Bug#568375: Bug#568375: gnupg-agent: does not work with `git tag -s`

Mon Feb 13 23:55:56 UTC 2017

On Mon 2017-02-13 17:13:07 -0500, Luca Capello wrote:
> On Sun, 12 Feb 2017 18:47:15 -0500, Daniel Kahn Gillmor wrote:
>> If this report is strictly about the yubikey smartcard, we should
>> reassign it to scdaemon.  Does "git tag -S" work for you when you are
>> *not* using a smartcard?
>
> Oh, sorry if I was not clear enough: no, `git tag -S` does now work
> without the YubiKey.

sorry to keep asking for clarification, but there are enough negations
above for me to be confused about whether "now" is a typo for "not" in
the sentence above.

> ...I tried everything again, starting with a fresh-new ~/.gnupg with
> GnuPG 1:

I do not expect gpg 1.4 to be co-operative with gpg 2.1 in several
different ways:

 * gpg 1.4 expects to find the agent to talk to by looking at
   $GPG_AGENT_INFO.  gpg 2.1 expects to use the "standard socket".

 * gpg 1.4 does not know how to ask the gpg-agent for use of the secret
   key material.  1.4 expects to ask the agent only for a passphrase,
   and needs to have secret key material in-process.

 * gpg 2.1 prefers to use a pubring.kbx format for its public keys.  1.4
   does not even know about this file, and wouldn't be able to parse it
   if it did know about it.

 * gpg 1.4 expects to connect directly to the active smartcard.  2.1
   expects access to the smartcard to be mediated by the scdaemon
   process.  I don't know what happens if both of these systems try to
   access a single smartcard concurrently, but i imagine it's not
   pretty.

We will continue to support gpg1 in debian for use by people with legacy
needs (e.g. decrypting archived data that was encrypted to old,
known-broken PGPv3 keys) but i do *not* expect it to "play nice" and
share keys, either private or public, with the 2.1.x series.

> $ gpg --default-key 3BE9F36D! --sign file.txt
>
> You need a passphrase to unlock the secret key for
> user: "Luca Capello <luca at pca.it>"
> 4096-bit RSA key, ID 3BE9F36D, created 2009-07-01 (main key ID E397832F)
>
> gpg: gpg-agent is not available in this session
> $ 
> =====
>
> WTF?

that's presumably due to a missing env var, as you show below:

> =====
> $ export GPG_TTY=$(tty)
> $ gpg --default-key 3BE9F36D! --sign file.txt
> [...]
> gpg: gpg-agent is not available in this session
> $ unset GPG_TTY
> $ export GPG_AGENT_INFO="$HOME/.gnupg/S.gpg-agent"
> $ gpg --default-key 3BE9F36D! --sign file.txt
> [...]
> gpg: malformed GPG_AGENT_INFO environment variable
> $ export GPG_AGENT_INFO="$HOME/.gnupg/S.gpg-agent:1"
> $ gpg --default-key 3BE9F36D! --sign file.txt
> [...]
> gpg: gpg-agent protocol version 0 is not supported
> $ export GPG_AGENT_INFO="$HOME/.gnupg/S.gpg-agent:2"
> $ gpg --default-key 3BE9F36D! --sign file.txt
> [...]
> gpg: gpg-agent protocol version 0 is not supported
> $ ls -l ~/.gnupg/private-keys-v1.d/
> total 0
> $
> =====
>
> OK, so I guess everything is as expected.

Sure, though i'm surprised to see you using "$HOME/.gnupg/S.gpg-agent"
as your socket path.  You should be setting this env var with a socket
path based on the name returned by "gpgconf --list-dirs agent-socket"
(or, on older verisons of 2.1.x, "gpgconf --list-dirs | grep
^agent-socket: | cut -f2 -d:").  please see
/etc/X11/Xsession.d/90gpg-agent for an example.

> Let me try with the YubiKey:
> =====
> [insert the YubiKey]
> $ gpg --card-status
> [...]
> General key info..: pub  4096R/675E1031 2016-02-22 Luca Capello <luca at pca.it>
> [...]
> $ git config --unset --global user.signingkey 3BE9F36D
> $ unset GPG_AGENT_INFO
> $ git commit -m 'file.txt: new file'
> gpg: signatures created so far: 1799
>
> Please enter the PIN
> [sigs done: 1799]
> gpg: gpg-agent is not available in this session
> Enter PIN:
> gpg: Interrupt caught ... exiting
>
> $ export GPG_TTY=$(tty)
> $ git commit -m 'file.txt: new file'
> [same as above]
> $ git commit -m 'file.txt: new file'
> gpg: signatures created so far: 1799
>
> Please enter the PIN
> [sigs done: 1799]
> gpg: gpg-agent is not available in this session
> [master (root-commit) 74bff88] file.txt: new file
>  1 file changed, 1 insertion(+)
>  create mode 100644 file.txt
> $ git tag -s -m 'test file' test_file
> gpg: signatures created so far: 1800
>
> Please enter the PIN
> [sigs done: 1800]
> gpg: gpg-agent is not available in this session
> $ 
> =====

Again, it looks to me like your env var for the agent isn't set
correctly.  but i don't think you're using the agent at all.  rather,
you're using 1.4's direct access to the smartcard.

> Let me try with GnuPG 2.1:
> =====
> $ ls -l /usr/bin/gpg
> lrwxrwxrwx 1 root root 4 Feb 13 22:26 /usr/bin/gpg -> gpg2

there is no debian system in which this is a standard configuration, and
the version of gpg in use here is, as already noted, not a part of
debian anywhere.  At some level, we're in "if you break this, you get to
keep both pieces" territory. :/

There's a lot for those of us on pkg-gnupg-maint to review and clean up
already with the stretch freeze, and i'm not sure how to responsibly
devote time to customized systems like this.  I want to help you make it
work for debian stretch, but 2.1.17 won't even install on a jessie
system afaict without a lot of other fiddling.

It would help me a lot if you could test and verify against debian
stretch or sid systems, so i can know whether the problems you're
reporting have actually already been fixed, otherwise i'm not sure how
to investigate or debug it myself.

Thanks for your work on trying to tackle these issues, Luca!

Regards,

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170213/818754b0/attachment.sig>