Debian Bug report logs - #568375
gnupg-agent: does not work with `git tag -s`

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Luca Capello <luca@pca.it>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: gnupg-agent: does not work with `git tag -s`

Date: Thu, 04 Feb 2010 12:32:21 +0100

[Message part 1 (text/plain, inline)]

Package: gnupg-agent
Version: 2.0.14-1
Severity: important

Hi there!

It seems that `git tag -s` and gpg-agent fails to cooperate and do not
show the pinentry dialog (in my case the -curses variant inside screen):
=====
luca@gismo:~/Lab/thesis/text(git)[master]$ \
 git tag -s -u E397832F -m "submitted" submitted $COMMIT

You need a passphrase to unlock the secret key for
user: "Luca Capello <luca@pca.it>"
4096-bit RSA key, ID 3BE9F36D, created 2009-07-01 (main key ID E397832F)

gpg: cancelled by user
gpg: skipped "E397832F": bad passphrase
gpg: signing failed: bad passphrase
error: gpg failed to sign the tag
error: unable to sign the tag

luca@gismo:~/Lab/thesis/text(git)[master]$
=====

The workaround is to do a `gpg --sign` before `git tag -s` and then
everything will work.

This is not the first time I need a workaround for gpg-agent/pinentry
(e.g. GNU Emacs Multi-TTY on text console), thus I still wonder why
there is not yet a pinentry implementation which mimics the old
behavior, i.e. it simply asks for a passphrase without the need to lock
the entire terminal or show a dialog window.

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnupg-agent depends on:
ii  libc6                         2.10.2-5   Embedded GNU C Library: Shared lib
ii  libgcrypt11                   1.4.5-1    LGPL Crypto library - runtime libr
ii  libgpg-error0                 1.6-1      library for common error values an
ii  libpth20                      2.0.7-14   The GNU Portable Threads
ii  libreadline6                  6.1-1      GNU readline and history libraries
ii  pinentry-curses [pinentry]    0.7.6-1    curses-based PIN or pass-phrase en

Versions of packages gnupg-agent recommends:
ii  gnupg                         1.4.10-2   GNU privacy guard - a free PGP rep

gnupg-agent suggests no packages.

-- no debconf information

[Message part 2 (application/pgp-signature, inline)]

Message #10 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Peter Colberg <peter@colberg.org>

To: Luca Capello <luca@pca.it>

Cc: 568375@bugs.debian.org

Subject: Re: gnupg-agent: does not work with `git tag -s`

Date: Sun, 20 Mar 2016 00:12:00 -0400

Hi Luca,

On Thu, Feb 04, 2010 at 12:32:21PM +0100, Luca Capello wrote:
> Package: gnupg-agent
> Version: 2.0.14-1
> Severity: important
> 
> Hi there!
> 
> It seems that `git tag -s` and gpg-agent fails to cooperate and do not
> show the pinentry dialog (in my case the -curses variant inside screen):
> =====
> luca@gismo:~/Lab/thesis/text(git)[master]$ \
>  git tag -s -u E397832F -m "submitted" submitted $COMMIT
> 
> You need a passphrase to unlock the secret key for
> user: "Luca Capello <luca@pca.it>"
> 4096-bit RSA key, ID 3BE9F36D, created 2009-07-01 (main key ID E397832F)
> 
> gpg: cancelled by user
> gpg: skipped "E397832F": bad passphrase
> gpg: signing failed: bad passphrase
> error: gpg failed to sign the tag
> error: unable to sign the tag

While this comes too late for signing the tag of your submitted thesis
(congratulations!), this is likely caused by a missing GPG_TTY variable.

https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html

The gpg-agent man page nowadays includes the following hint:

  It is important to set the GPG_TTY environment variable in your login
  shell, for example in the ‘~/.bashrc’ init script:

  export GPG_TTY=$(tty)

Regards,
Peter

Message #15 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Michal Hocko <mstsxfx@gmail.com>

To: Peter Colberg <peter@colberg.org>

Cc: Luca Capello <luca@pca.it>, 568375@bugs.debian.org

Subject: Re: gnupg-agent: does not work with `git tag -s`

Date: Thu, 12 Jan 2017 11:59:34 +0100

On Sun, Mar 20, 2016 at 12:12:00AM -0400, Peter Colberg wrote:
> Hi Luca,
> 
> On Thu, Feb 04, 2010 at 12:32:21PM +0100, Luca Capello wrote:
> > Package: gnupg-agent
> > Version: 2.0.14-1
> > Severity: important
> > 
> > Hi there!
> > 
> > It seems that `git tag -s` and gpg-agent fails to cooperate and do not
> > show the pinentry dialog (in my case the -curses variant inside screen):
> > =====
> > luca@gismo:~/Lab/thesis/text(git)[master]$ \
> >  git tag -s -u E397832F -m "submitted" submitted $COMMIT
> > 
> > You need a passphrase to unlock the secret key for
> > user: "Luca Capello <luca@pca.it>"
> > 4096-bit RSA key, ID 3BE9F36D, created 2009-07-01 (main key ID E397832F)
> > 
> > gpg: cancelled by user
> > gpg: skipped "E397832F": bad passphrase
> > gpg: signing failed: bad passphrase
> > error: gpg failed to sign the tag
> > error: unable to sign the tag
> 
> While this comes too late for signing the tag of your submitted thesis
> (congratulations!), this is likely caused by a missing GPG_TTY variable.
> 
> https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html
> 
> The gpg-agent man page nowadays includes the following hint:
> 
>   It is important to set the GPG_TTY environment variable in your login
>   shell, for example in the ‘~/.bashrc’ init script:
> 
>   export GPG_TTY=$(tty)

So I've tried this and it didn't help.
$ export GPG_TTY=$(tty)
$ git tag -s -u $ID ...

I get the password dialog but nothing really happens after then.

16699 pts/1    S+     0:00         git tag -s -u B310E347
16700 pts/1    SL+    0:00           gpg --status-fd=2 -bsau B310E347

gpg is stuck waiting for an input
$ strace -p 16700
strace: Process 16700 attached
read(4,

$ ll /proc/16700/fd/4 
lrwx------ 1 miso miso 64 Jan 12 11:54 /proc/16700/fd/4 -> socket:[2711665]

but it never gets anything while gpg-agent is hogging the cpu
16703 ?        Ssl    3:05 gpg-agent --homedir /home/miso/.gnupg --use-standard-socket --daemon

Note that /proc/16703/environ contains GPG_TTY...

$ strace -fp 16703
strace: Process 16703 attached with 2 threads
strace: [ Process PID=16704 runs in x32 mode. ]
[pid 16703] pselect6(8, [3 4 5 6 7], NULL, NULL, NULL, {[], 8}

nothing really more, so it seems that the process is looping in the userspace.
Is there any way to disable gpg-agent altogether?

Thanks!
-- 
Michal Hocko

Message #20 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Michal Hocko <mstsxfx@gmail.com>

To: Peter Colberg <peter@colberg.org>

Cc: Luca Capello <luca@pca.it>, 568375@bugs.debian.org

Subject: Re: gnupg-agent: does not work with `git tag -s`

Date: Thu, 12 Jan 2017 12:19:47 +0100

On Thu, Jan 12, 2017 at 11:59:34AM +0100, Michal Hocko wrote:
> On Sun, Mar 20, 2016 at 12:12:00AM -0400, Peter Colberg wrote:
> > Hi Luca,
> > 
> > On Thu, Feb 04, 2010 at 12:32:21PM +0100, Luca Capello wrote:
> > > Package: gnupg-agent
> > > Version: 2.0.14-1
> > > Severity: important
> > > 
> > > Hi there!
> > > 
> > > It seems that `git tag -s` and gpg-agent fails to cooperate and do not
> > > show the pinentry dialog (in my case the -curses variant inside screen):
> > > =====
> > > luca@gismo:~/Lab/thesis/text(git)[master]$ \
> > >  git tag -s -u E397832F -m "submitted" submitted $COMMIT
> > > 
> > > You need a passphrase to unlock the secret key for
> > > user: "Luca Capello <luca@pca.it>"
> > > 4096-bit RSA key, ID 3BE9F36D, created 2009-07-01 (main key ID E397832F)
> > > 
> > > gpg: cancelled by user
> > > gpg: skipped "E397832F": bad passphrase
> > > gpg: signing failed: bad passphrase
> > > error: gpg failed to sign the tag
> > > error: unable to sign the tag
> > 
> > While this comes too late for signing the tag of your submitted thesis
> > (congratulations!), this is likely caused by a missing GPG_TTY variable.
> > 
> > https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html
> > 
> > The gpg-agent man page nowadays includes the following hint:
> > 
> >   It is important to set the GPG_TTY environment variable in your login
> >   shell, for example in the ‘~/.bashrc’ init script:
> > 
> >   export GPG_TTY=$(tty)
> 
> So I've tried this and it didn't help.
> $ export GPG_TTY=$(tty)
> $ git tag -s -u $ID ...
> 
> I get the password dialog but nothing really happens after then.
> 
> 16699 pts/1    S+     0:00         git tag -s -u B310E347
> 16700 pts/1    SL+    0:00           gpg --status-fd=2 -bsau B310E347
> 
> gpg is stuck waiting for an input
> $ strace -p 16700
> strace: Process 16700 attached
> read(4,
> 
> $ ll /proc/16700/fd/4 
> lrwx------ 1 miso miso 64 Jan 12 11:54 /proc/16700/fd/4 -> socket:[2711665]
> 
> but it never gets anything while gpg-agent is hogging the cpu
> 16703 ?        Ssl    3:05 gpg-agent --homedir /home/miso/.gnupg --use-standard-socket --daemon

Btw. gnupgp-agen 2.0.26-6+deb8u1 and gpnupg 1.4.18-7+deb8u3 versions
seem to be working just fine.

-- 
Michal Hocko

Message #25 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Luca Capello <luca@pca.it>

To: Michal Hocko <mstsxfx@gmail.com>

Cc: Peter Colberg <peter@colberg.org>, 568375@bugs.debian.org

Subject: Re: gnupg-agent: does not work with `git tag -s`

Date: Sun, 12 Feb 2017 22:52:29 +0100

[Message part 1 (text/plain, inline)]

found 568375 2.1.11-7
thanks

Hi there,

On Thu, 12 Jan 2017 11:59:34 +0100, Michal Hocko wrote:
> On Sun, Mar 20, 2016 at 12:12:00AM -0400, Peter Colberg wrote:
> > On Thu, Feb 04, 2010 at 12:32:21PM +0100, Luca Capello wrote:
> > > It seems that `git tag -s` and gpg-agent fails to cooperate and do not
> > > show the pinentry dialog (in my case the -curses variant inside screen):
[...]
> > While this comes too late for signing the tag of your submitted thesis
> > (congratulations!), this is likely caused by a missing GPG_TTY variable.
> > 
> > https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html
> > 
> > The gpg-agent man page nowadays includes the following hint:
> > 
> >   It is important to set the GPG_TTY environment variable in your login
> >   shell, for example in the ‘~/.bashrc’ init script:
> > 
> >   export GPG_TTY=$(tty)
>
> So I've tried this and it didn't help.
> $ export GPG_TTY=$(tty)

Actually, even worse, commit does not work with gnupg2_2.1.11-7:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974#35>

=====
$ mkdir test.git
$ cd test.git/
$ git init
Initialized empty Git repository in $HOME/test.git/.git/
$ echo 'test file' >file.txt
$ git add file.txt
$ export GPG_TTY=$(tty)
$ git commit -m 'file.txt: new file'
gpg: signing failed: Card error
gpg: signing failed: Card error
error: gpg failed to sign the data
fatal: failed to write commit object
$ gpg --version | head -n 1
gpg (GnuPG) 2.1.11
$ gpg --sign file.txt
gpg: using "139121880F512EC2E6A464D3D91D57A03BE9F36D!" as default secret key for signing
$
=====

What is funny is that if I plug my YubiKey 4 (basically an OpenPGP
smartcard) everything (commit + tag) is fine (tested on 2 different
jessie).

BTW, the above gpg message about default secret key is actually useless
     and it is a result of having to specifying the default-key:
     
       <https://bugs.debian.org/829246>

> $ git tag -s -u $ID ...
> 
> I get the password dialog but nothing really happens after then.
> 
> 16699 pts/1    S+     0:00         git tag -s -u B310E347
> 16700 pts/1    SL+    0:00           gpg --status-fd=2 -bsau B310E347
> 
> gpg is stuck waiting for an input

Is that GnuPG 1 or GnuPG 2?

> nothing really more, so it seems that the process is looping in the userspace.
> Is there any way to disable gpg-agent altogether?

Not with GnuPG 2+.

Thx, bye,
Gismo / Luca

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Luca Capello <luca@pca.it>, 568375@bugs.debian.org, Michal Hocko <mstsxfx@gmail.com>

Cc: Peter Colberg <peter@colberg.org>

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

Date: Sun, 12 Feb 2017 18:47:15 -0500

On Sun 2017-02-12 16:52:29 -0500, Luca Capello wrote:
> Actually, even worse, commit does not work with gnupg2_2.1.11-7:
>
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974#35>

I'm surprised to see a report about 2.1.11-7 on 2017-02-12 when that
package was superceded 10 days ago by 2.1.18-3.  Is there a reason that
you're using 2.1.11-7, which is no longer in debian?

> What is funny is that if I plug my YubiKey 4 (basically an OpenPGP
> smartcard) everything (commit + tag) is fine (tested on 2 different
> jessie).

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?

Please see https://bugs.debian.org/854005 and
https://bugs.debian.org/854616 for more diagnostic approaches that might
help you with your yubikey.

     --dkg

Message #37 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Luca Capello <luca@pca.it>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 568375@bugs.debian.org, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Mon, 13 Feb 2017 23:13:07 +0100

[Message part 1 (text/plain, inline)]

Hi there,

On Sun, 12 Feb 2017 18:47:15 -0500, Daniel Kahn Gillmor wrote:
> On Sun 2017-02-12 16:52:29 -0500, Luca Capello wrote:
> > Actually, even worse, commit does not work with gnupg2_2.1.11-7:
> >
> >   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974#35>
> 
> I'm surprised to see a report about 2.1.11-7 on 2017-02-12 when that
> package was superceded 10 days ago by 2.1.18-3.  Is there a reason that
> you're using 2.1.11-7, which is no longer in debian?

Yes, AFAIK it is the only way to have GnuPG 2.1 (to have gpg-agent
forwarding) on jessie, as I explained in the other bug report I linked.
This is also why I am working on the jessie-backports ;-)

> > What is funny is that if I plug my YubiKey 4 (basically an OpenPGP
> > smartcard) everything (commit + tag) is fine (tested on 2 different
> > jessie).
> 
> 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.

Given that I had actually missed Mickael's second post...

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568375#20>

...I tried everything again, starting with a fresh-new ~/.gnupg with
GnuPG 1:
=====
$ gpg --version | head -n 1
gpg (GnuPG) 1.4.18
$ gpg --list-secret-keys
$HOME/.gnupg/secring.gpg
-------------------------------------------
sec#  4096R/E397832F 2009-07-01
uid                  Luca Capello <luca@pca.it>
uid                  Luca Capello <gismo@debian.org>
uid                  Luca Capello <luca.capello@infomaniak.ch>
uid                  Luca Capello <luca.capello@infomaniak.com>
ssb   4096R/3BE9F36D 2009-07-01
ssb#  4096R/2BB95F4B 2009-07-01
ssb>  4096R/675E1031 2016-02-22
ssb>  4096R/A0ACD061 2016-02-22
ssb>  4096R/D18542FA 2016-02-22
$ grep -v -e '^#' -e '^$' ~/.gnupg/gpg.conf
keyserver hkp://keys.gnupg.net
$ echo 'use-agent' >>~/.gnupg/gpg.conf
$ eval $(gpg-agent --daemon)
gpg-agent[13561]: directory $HOME/.gnupg/private-keys-v1.d' created
gpg-agent[13562]: gpg-agent (GnuPG) 2.1.11 started
$ mkdir test.git
$ cd test.git/
$ git init
Initialized empty Git repository in $HOME/test.git/.git/
$ echo 'test file' >file.txt
$ git add file.txt
$ git commit -m 'file.txt: new file'
gpg: pcsc_establish_context failed: no service (0x8010001d)
gpg: card reader not available
gpg: signing failed: general error
gpg: signing failed: general error
error: gpg failed to sign the data
fatal: failed to write commit object
$ git config --global user.signingkey 3BE9F36D
$ git commit -m 'file.txt: new file'
[error as above]
$ gpg --sign file.txt
[error as above]
$ gpg --default-key 3BE9F36D --sign file.txt
[error as above]
$ gpg --default-key E397832F --sign file.txt
[error as above]
$ gpg --default-key 3BE9F36D! --sign file.txt

You need a passphrase to unlock the secret key for
user: "Luca Capello <luca@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?

=====
$ 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.

Let me try with the YubiKey:
=====
[insert the YubiKey]
$ gpg --card-status
[...]
General key info..: pub  4096R/675E1031 2016-02-22 Luca Capello <luca@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
$ 
=====

Similar to #802586, ssh works fine:
=====
$ pkill gpg-agent
$ echo 'enable-ssh-support' >~/.gnupg/gpg-agent.conf
$ eval $(gpg-agent --daemon)
$ ssh-add -l
4096 57:df:0d:67:82:4a:7f:80:15:80:5f:48:e6:e6:ae:06 cardno:0123456789ab (RSA)
$
=====

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
$ gpg --version | head -n 1
gpg (GnuPG) 2.1.11
$ gpg --list-secret-keys
/home/users/luca.capello/.gnupg/pubring.kbx
-------------------------------------------
sec#  rsa4096/E397832F 2009-07-01 [SC]
uid         [ unknown] Luca Capello <luca@pca.it>
uid         [ unknown] Luca Capello <gismo@debian.org>
uid         [ unknown] Luca Capello <luca.capello@infomaniak.ch>
uid         [ unknown] Luca Capello <luca.capello@infomaniak.com>
ssb   rsa4096/3BE9F36D 2009-07-01 [SEA]
ssb#  rsa4096/2BB95F4B 2009-07-01 [E]
ssb#  rsa4096/675E1031 2016-02-22 [S] [expires: 2018-02-21]
ssb#  rsa4096/A0ACD061 2016-02-22 [E] [expires: 2018-02-21]
ssb#  rsa4096/D18542FA 2016-02-22 [A] [expires: 2018-02-21]

$ grep -v -e '^#' -e '^$' ~/.gnupg/gpg.conf
$ mkdir test.git
$ cd test.git/
$ git init
Initialized empty Git repository in $HOME/test.git/.git/
$ echo 'test file' >file.txt
$ git add file.txt
$ git commit -m 'file.txt: new file'
gpg: signing failed: No secret key
gpg: signing failed: No secret key
error: gpg failed to sign the data
fatal: failed to write commit object
$ git config --global user.signingkey 3BE9F36D
$ git commit -m 'file.txt: new file'
[same error as above, this is #829246]
$ git config --global user.signingkey 3BE9F36D!
$ git commit -m 'file.txt: new file'
[master (root-commit) bfeb91c] file.txt: new file
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt
$ git tag -s -m 'test file' test_file
$
=====

FTR, with `git config --global user.signingkey 3BE9F36D!`, `git commit`
works with gpg1 as well, still without the agent.

> Please see https://bugs.debian.org/854005

Nothing related to GnuPG, but I am very sad that we need to ship the
same rules in at least 3 different debpkg:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846359#44>

Thx, bye,
Gismo / Luca

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Luca Capello <luca@pca.it>

Cc: 568375@bugs.debian.org, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Mon, 13 Feb 2017 18:55:56 -0500

[Message part 1 (text/plain, inline)]

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@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@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

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Werner Koch <wk@gnupg.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 568375@bugs.debian.org, Luca Capello <luca@pca.it>, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Wed, 15 Feb 2017 11:24:34 +0100

[Message part 1 (text/plain, inline)]

On Tue, 14 Feb 2017 00:55, dkg@fifthhorseman.net said:

>  * 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

If gpg 1.4 can access the card via agent+scdaemon it uses these daemons
to access the card.  Thus many things should work.

If 1.4 can't do that it uses an old copy of the code used by scdaemon to
access the card.  That code is old and thus a lot of things won't work.

I can't suggest to use 1.4 with smardcards.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

[Message part 2 (application/pgp-signature, inline)]

Message #52 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Werner Koch <wk@gnupg.org>

Cc: 568375@bugs.debian.org, Luca Capello <luca@pca.it>, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Wed, 15 Feb 2017 10:23:27 -0500

[Message part 1 (text/plain, inline)]

On Wed 2017-02-15 05:24:34 -0500, Werner Koch wrote:
> On Tue, 14 Feb 2017 00:55, dkg@fifthhorseman.net said:
>
>>  * 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
>
> If gpg 1.4 can access the card via agent+scdaemon it uses these daemons
> to access the card.  Thus many things should work.
>
> If 1.4 can't do that it uses an old copy of the code used by scdaemon to
> access the card.  That code is old and thus a lot of things won't work.
>
> I can't suggest to use 1.4 with smardcards.

should we adjust the build of 1.4 in debian to patch out the direct
access of smartcards?  if we use --disable-card-support during
./configure will that disable use of the agent for smartcards as well,
or will it just remove the direct access?

       --dkg

[signature.asc (application/pgp-signature, inline)]

Message #57 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Werner Koch <wk@gnupg.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 568375@bugs.debian.org, Luca Capello <luca@pca.it>, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Wed, 15 Feb 2017 19:33:57 +0100

[Message part 1 (text/plain, inline)]

On Wed, 15 Feb 2017 16:23, dkg@fifthhorseman.net said:

> should we adjust the build of 1.4 in debian to patch out the direct
> access of smartcards?  if we use --disable-card-support during
> ./configure will that disable use of the agent for smartcards as well,
> or will it just remove the direct access?

--disable-card-support removes all support for smartcards.  I would not
mind if you use that option.

--disable-agent-support without --disable-card-support will only use the
direct smartcard access code.  Thus is is the opposite of what you want.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

[Message part 2 (application/pgp-signature, inline)]

Message #62 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Werner Koch <wk@gnupg.org>

Cc: 568375@bugs.debian.org, Luca Capello <luca@pca.it>, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Wed, 15 Feb 2017 14:52:18 -0500

[Message part 1 (text/plain, inline)]

On Wed 2017-02-15 13:33:57 -0500, Werner Koch wrote:
> On Wed, 15 Feb 2017 16:23, dkg@fifthhorseman.net said:
>
>> should we adjust the build of 1.4 in debian to patch out the direct
>> access of smartcards?  if we use --disable-card-support during
>> ./configure will that disable use of the agent for smartcards as well,
>> or will it just remove the direct access?
>
> --disable-card-support removes all support for smartcards.  I would not
> mind if you use that option.

However, this will cause problems for people dealing with a smartcard
with a PGPv3 key on it.

We're maintaining gpg1 in debian specifically for people who have legacy
setup like this, so they can access archived messages.  Ripping away
smartcard support from them seems like the wrong move.  Unless maybe
it's impossible for there to be any PGPv3 secret keys on smartcards?

> --disable-agent-support without --disable-card-support will only use the
> direct smartcard access code.  Thus is is the opposite of what you want.

hm, bummer.  a configure option to keep the agent access but not the
direct smartcard access would be nice to have.

       --dkg

[signature.asc (application/pgp-signature, inline)]

Message #67 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Werner Koch <wk@gnupg.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 568375@bugs.debian.org, Luca Capello <luca@pca.it>, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Thu, 16 Feb 2017 17:37:55 +0100

[Message part 1 (text/plain, inline)]

On Wed, 15 Feb 2017 20:52, dkg@fifthhorseman.net said:

> However, this will cause problems for people dealing with a smartcard
> with a PGPv3 key on it.

I doubt that you can put a PGP-2 key on an OpenPGP smartcard.  We
require a SHA-1 fingerprint.

> hm, bummer.  a configure option to keep the agent access but not the
> direct smartcard access would be nice to have.

Feel free to add a request, but I dount that we will implement that.
Maintaining the smartcard code in 1.4 is way to much work.  Testing is
the major problem.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

[Message part 2 (application/pgp-signature, inline)]

Message #72 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Werner Koch <wk@gnupg.org>

Cc: 568375@bugs.debian.org, Luca Capello <luca@pca.it>, Michal Hocko <mstsxfx@gmail.com>, Peter Colberg <peter@colberg.org>

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

Date: Thu, 16 Feb 2017 20:29:14 -0500

[Message part 1 (text/plain, inline)]

On Thu 2017-02-16 11:37:55 -0500, Werner Koch wrote:
> On Wed, 15 Feb 2017 20:52, dkg@fifthhorseman.net said:
>
>> However, this will cause problems for people dealing with a smartcard
>> with a PGPv3 key on it.
>
> I doubt that you can put a PGP-2 key on an OpenPGP smartcard.  We
> require a SHA-1 fingerprint.

ok, this makes me think we really should just use
--disable-smartcard-support on gnupg1, and encourage all smartcard users
to migrate over to modern GnuPG and scdaemon.  I've followed up about
that over in https://bugs.debian.org/810417

Thanks for the feedback!

   --dkg

[signature.asc (application/pgp-signature, inline)]

Message #77 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Michal Hocko <mstsxfx@gmail.com>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: Luca Capello <luca@pca.it>, 568375@bugs.debian.org, Peter Colberg <peter@colberg.org>

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

Date: Thu, 23 Feb 2017 16:55:24 +0100

On Sun, Feb 12, 2017 at 06:47:15PM -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?

Well I am not using any smartcards. I just have my private keyring on an
USB flash disk and 
~/.gnupg/secring.gpg -> /mnt/security/.gnupg/secring.gpg

but that shouldn't matter, right?
-- 
Michal Hocko

Message #82 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Michal Hocko <mstsxfx@gmail.com>

Cc: Luca Capello <luca@pca.it>, 568375@bugs.debian.org, Peter Colberg <peter@colberg.org>

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

Date: Thu, 23 Feb 2017 11:22:32 -0500

[Message part 1 (text/plain, inline)]

On Thu 2017-02-23 10:55:24 -0500, Michal Hocko <mstsxfx@gmail.com> wrote:
> On Sun, Feb 12, 2017 at 06:47:15PM -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?
>
> Well I am not using any smartcards. I just have my private keyring on an
> USB flash disk and 
> ~/.gnupg/secring.gpg -> /mnt/security/.gnupg/secring.gpg
>
> but that shouldn't matter, right?

gpg 2.1 does not store or use secret keys in the same way as 1.4.  In
particular, secring.gpg is no longer used, and secret key material is
stored in ~/.gnupg/private-keys-v1.d/

if you want to continue to use your USB flash disk, i recommend (when
the USB disk is inserted and mounted):

  if [ -d ~/.gnupg/private-keys-v1.d ]; then
     mv ~/.gnupg/private-keys-v1.d /mnt/security/.gnupg/
  else
     mkdir -m 0700 /mnt/security/.gnupg/private-keys-v1.d
  fi
  ln -s /mnt/security/.gnupg/private-keys-v1.d ~/.gnupg/private-keys-v1.d
  if [ -L ~/.gnupg/secring.gpg ]; thne
     rm ~/.gnupg/secring.gpg
  fi
  gpg --batch --import < /mnt/security/.gnupg/secring.gpg

Once this is done and you're sure you have access to the secret keys you
want, you can also delete /mnt/security/.gnupg/secring.gpg.

hope this helps,

     --dkg

[signature.asc (application/pgp-signature, inline)]

Message #87 received at 568375@bugs.debian.org (full text, mbox, reply):

From: Michal Hocko <mstsxfx@gmail.com>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: Luca Capello <luca@pca.it>, 568375@bugs.debian.org, Peter Colberg <peter@colberg.org>

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

Date: Mon, 27 Feb 2017 21:01:31 +0100

On Thu, Feb 23, 2017 at 11:22:32AM -0500, Daniel Kahn Gillmor wrote:
> On Thu 2017-02-23 10:55:24 -0500, Michal Hocko <mstsxfx@gmail.com> wrote:
> > On Sun, Feb 12, 2017 at 06:47:15PM -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?
> >
> > Well I am not using any smartcards. I just have my private keyring on an
> > USB flash disk and 
> > ~/.gnupg/secring.gpg -> /mnt/security/.gnupg/secring.gpg
> >
> > but that shouldn't matter, right?
> 
> gpg 2.1 does not store or use secret keys in the same way as 1.4.  In
> particular, secring.gpg is no longer used, and secret key material is
> stored in ~/.gnupg/private-keys-v1.d/
> 
> if you want to continue to use your USB flash disk, i recommend (when
> the USB disk is inserted and mounted):
> 
>   if [ -d ~/.gnupg/private-keys-v1.d ]; then
>      mv ~/.gnupg/private-keys-v1.d /mnt/security/.gnupg/
>   else
>      mkdir -m 0700 /mnt/security/.gnupg/private-keys-v1.d
>   fi
>   ln -s /mnt/security/.gnupg/private-keys-v1.d ~/.gnupg/private-keys-v1.d
>   if [ -L ~/.gnupg/secring.gpg ]; thne
>      rm ~/.gnupg/secring.gpg
>   fi
>   gpg --batch --import < /mnt/security/.gnupg/secring.gpg
> 
> Once this is done and you're sure you have access to the secret keys you
> want, you can also delete /mnt/security/.gnupg/secring.gpg.
> 
> hope this helps,

unfortunatelly nope. The same problem I saw the last time. I get a
password prompt and then gpg agent hogs one CPU, so basically the same
situation I have described earlier (email 12 Jan 2017 - message-id
20170112105934.GA16651@dhcp22.suse.cz).
-- 
Michal Hocko

Send a report that this bug log contains spam.