Debian Bug report logs - #854005
ssh-agent no longer works

Display info messages

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

From: Wouter Verhelst <wouter@debian.org>

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

Subject: ssh-agent no longer works

Date: Thu, 02 Feb 2017 23:54:26 +0100

Package: gnupg-agent
Version: 2.1.18-3
Severity: normal

Hi,

Since a recent upgrade, gnupg-agent no longer finds the authentication
(SSH) key on my OpenPGP smartcard:

wouter@gangtai:~$ gpg --card-status

Reader ...........: ACS ACR38U 00 00
Application ID ...: D2760001240102010005000047360000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 00004736
Name of cardholder: Wouter Verhelst
Language prefs ...: nl
Sex ..............: male
URL of public key :
http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x9B69FDF3F0DA0948066129F72DFC519954181296
Login data .......: [not set]
Signature PIN ....: forced
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 116
Signature key ....: 9B69 FDF3 F0DA 0948 0661  29F7 2DFC 5199 5418 1296
      created ....: 2016-04-11 11:46:27
Encryption key....: B057 2256 DD3D 8275 A1F2  3015 EBC4 535B 0557 DB14
      created ....: 2016-04-11 11:46:27
Authentication key: B7D1 52E7 6233 6135 DBEF  6435 965E 159D 1F28 844B
      created ....: 2016-04-11 11:46:27
General key info..: pub  rsa4096/2DFC519954181296 2016-04-11 Wouter
Verhelst <w@uter.be>
sec>  rsa4096/2DFC519954181296  created: 2016-04-11  expires: never     
                                card-no: 0005 00004736
ssb>  rsa4096/965E159D1F28844B  created: 2016-04-11  expires: never     
                                card-no: 0005 00004736
ssb>  rsa4096/EBC4535B0557DB14  created: 2016-04-11  expires: never     
                                card-no: 0005 00004736
wouter@gangtai:~$ echo "foo bar" | gpg -r 54181296 -e | gpg
gpg: please do a --check-trustdb
gpg: 54181296: skipped: public key already present
gpg: encrypted with 4096-bit RSA key, ID EBC4535B0557DB14, created
2016-04-11
      "Wouter Verhelst <w@uter.be>"
foo bar
wouter@gangtai:~$ echo $SSH_AUTH_SOCK 
/run/user/1000/gnupg/S.gpg-agent.ssh
wouter@gangtai:~$ ssh-add -l
The agent has no identities.

The interesting part of the above is that the last command (the "ssh-add
-l" bit) actually reads from the card (I can see the cardreader LED
flash).  It just doesn't find anything.

Note: I removed the "90gpg-agent" file from Xsession.d, since it messes
up some other SSH key setup that I have, very much in the same way that
gnome-keyring messes up gpg-agent. With the previous version of
gpg-agent, it was enough to just run "gpg --card-status" to start the
agent and make the ssh key stuff work.

Having to fight with all of that is pretty ironic, given that ssh-agent
actually supports external modules through PKCS#11. Ah well.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg-agent depends on:
ii  libassuan0                  2.4.3-2
ii  libc6                       2.24-9
ii  libgcrypt20                 1.7.6-1
ii  libgpg-error0               1.26-2
ii  libnpth0                    1.3-1
ii  libreadline7                7.0-2
ii  pinentry-curses [pinentry]  1.0.0-1
ii  pinentry-gnome3 [pinentry]  1.0.0-1

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.18-3

Versions of packages gnupg-agent suggests:
ii  dbus-user-session  1.10.14-1
ii  libpam-systemd     232-15
ii  pinentry-gnome3    1.0.0-1
ii  scdaemon           2.1.18-3

-- Configuration Files:
/etc/X11/Xsession.d/90gpg-agent changed:


-- no debconf information

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

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

To: Wouter Verhelst <wouter@debian.org>, 854005@bugs.debian.org

Cc: NIIBE Yutaka <gniibe@fsij.org>

Subject: Re: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Thu, 02 Feb 2017 19:03:37 -0500

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

Control: reassign 854005 scdaemon

Hi Wouter--

On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote:
> Since a recent upgrade, gnupg-agent no longer finds the authentication
> (SSH) key on my OpenPGP smartcard:
>
> wouter@gangtai:~$ gpg --card-status
>
> Reader ...........: ACS ACR38U 00 00
> Application ID ...: D2760001240102010005000047360000
> Version ..........: 2.1
> Manufacturer .....: ZeitControl
> Serial number ....: 00004736
> Name of cardholder: Wouter Verhelst
> Language prefs ...: nl
> Sex ..............: male
> URL of public key :
> http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x9B69FDF3F0DA0948066129F72DFC519954181296
> Login data .......: [not set]
> Signature PIN ....: forced
> Max. PIN lengths .: 32 32 32
> PIN retry counter : 3 0 3
> Signature counter : 116
> Signature key ....: 9B69 FDF3 F0DA 0948 0661  29F7 2DFC 5199 5418 1296
>       created ....: 2016-04-11 11:46:27
> Encryption key....: B057 2256 DD3D 8275 A1F2  3015 EBC4 535B 0557 DB14
>       created ....: 2016-04-11 11:46:27
> Authentication key: B7D1 52E7 6233 6135 DBEF  6435 965E 159D 1F28 844B
>       created ....: 2016-04-11 11:46:27
> General key info..: pub  rsa4096/2DFC519954181296 2016-04-11 Wouter
> Verhelst <w@uter.be>
> sec>  rsa4096/2DFC519954181296  created: 2016-04-11  expires: never     
>                                 card-no: 0005 00004736
> ssb>  rsa4096/965E159D1F28844B  created: 2016-04-11  expires: never     
>                                 card-no: 0005 00004736
> ssb>  rsa4096/EBC4535B0557DB14  created: 2016-04-11  expires: never     
>                                 card-no: 0005 00004736
> wouter@gangtai:~$ echo "foo bar" | gpg -r 54181296 -e | gpg
> gpg: please do a --check-trustdb
> gpg: 54181296: skipped: public key already present
> gpg: encrypted with 4096-bit RSA key, ID EBC4535B0557DB14, created
> 2016-04-11
>       "Wouter Verhelst <w@uter.be>"
> foo bar
> wouter@gangtai:~$ echo $SSH_AUTH_SOCK 
> /run/user/1000/gnupg/S.gpg-agent.ssh
> wouter@gangtai:~$ ssh-add -l
> The agent has no identities.
>
> The interesting part of the above is that the last command (the "ssh-add
> -l" bit) actually reads from the card (I can see the cardreader LED
> flash).  It just doesn't find anything.
>
> Note: I removed the "90gpg-agent" file from Xsession.d, since it messes
> up some other SSH key setup that I have, very much in the same way that
> gnome-keyring messes up gpg-agent. With the previous version of
> gpg-agent, it was enough to just run "gpg --card-status" to start the
> agent and make the ssh key stuff work.
>
> Having to fight with all of that is pretty ironic, given that ssh-agent
> actually supports external modules through PKCS#11. Ah well.

i don't have such a device to test with, so i'm not sure how to debug
this with you, but it sounds like it may be an issue with scdaemon
itself, so i'm reassigning it there and cc'ing gniibe in the hopes that
he can provide some insight.

is the key you expect to use listed in ~/.gnupg/sshcontrol ?  I'd expect
it to be listed by its keygrip, which i think is:

    40277D42041E8A6E9AC9206FB335DDBA4B57A505

thanks for the report!

    --dkg

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

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

From: NIIBE Yutaka <gniibe@fsij.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <wouter@debian.org>

Cc: 854005@bugs.debian.org

Subject: Re: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Fri, 03 Feb 2017 09:40:35 +0900

Hello,

Thanks to dkg to explicitly CC me.

On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote:
> Since a recent upgrade, gnupg-agent no longer finds the authentication
> (SSH) key on my OpenPGP smartcard:
>
> wouter@gangtai:~$ gpg --card-status

It should be an issue of scdaemon.  For 2.1.18, I added multiple card
reader support.  This might be a possible cause.  Please let me know, if
2.1.17 worked fine or not.

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> is the key you expect to use listed in ~/.gnupg/sshcontrol ?  I'd expect
> it to be listed by its keygrip, which i think is:
>
>     40277D42041E8A6E9AC9206FB335DDBA4B57A505

No, this line is not needed for card; It is automatically available for
auth key on card.

I'm now at NRT airport to BRU.  So, I won't be available for 12 hours or
so.
-- 

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

From: Wouter Verhelst <w@uter.be>

To: NIIBE Yutaka <gniibe@fsij.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 854005@bugs.debian.org

Subject: Re: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Fri, 3 Feb 2017 12:08:02 +0100

On Fri, Feb 03, 2017 at 09:40:35AM +0900, NIIBE Yutaka wrote:
> Hello,
> 
> Thanks to dkg to explicitly CC me.
> 
> On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote:
> > Since a recent upgrade, gnupg-agent no longer finds the authentication
> > (SSH) key on my OpenPGP smartcard:
> >
> > wouter@gangtai:~$ gpg --card-status
> 
> It should be an issue of scdaemon.  For 2.1.18, I added multiple card
> reader support.

Awesome! That's been something I've been wanting to look into myself for
quite a while now. Good that I don't have to anymore ;-)

> This might be a possible cause.  Please let me know, if 2.1.17 worked
> fine or not.

I just downgraded to 2.1.17-6 (using snapshot.debian.org), and all works
fine again.

Side note (this might be related, but didn't think of that last night):

wouter@gangtai:~$ cat .gnupg/scdaemon.conf
reader-port O2 Micro Oz776 01 00
log-file /home/wouter/.gnupg/scdaemon.log
pcsc-driver libpcsclite.so

I did fiddle with the "reader-port" line a bit last night, but that
didn't fix things. Given that 2.1.18 does multi card reader support,
that may no longer be needed, either.

The "pcsc-driver" is necessary in my case, otherwise my day job
(supporting the software on http://eid.belgium.be) becomes very tedious
(and is also why I sometimes have two or three card readers connected to
my laptop at the same time...).

> Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> > is the key you expect to use listed in ~/.gnupg/sshcontrol ?  I'd expect
> > it to be listed by its keygrip, which i think is:
> >
> >     40277D42041E8A6E9AC9206FB335DDBA4B57A505
> 
> No, this line is not needed for card; It is automatically available for
> auth key on card.
> 
> I'm now at NRT airport to BRU.

Interesting. I live 10 minutes away (by train) from that airport :-)

I take it you'll be at FOSDEM? I'll be giving a talk in the
IaaS/Virtualization devroom at 14:00 on saturday[1]. If it helps, I'll
have my laptop with me (and a few cardreaders too, probably); we can
then debug things face to face if you want me to.

[1] https://fosdem.org/2017/schedule/event/iaas_netblodev/

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

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

From: NIIBE Yutaka <gniibe@fsij.org>

To: Wouter Verhelst <w@uter.be>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 854005@bugs.debian.org

Subject: Re: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Sat, 04 Feb 2017 01:30:52 +0900

Wouter Verhelst <w@uter.be> wrote:
> wouter@gangtai:~$ cat .gnupg/scdaemon.conf
> reader-port O2 Micro Oz776 01 00
> log-file /home/wouter/.gnupg/scdaemon.log
> pcsc-driver libpcsclite.so

Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC
is somehow broken in 2.1.18.  Please try with internal CCID driver of
GnuPG.  I mean, don't use PC/SC service.

>> I'm now at NRT airport to BRU.
>
> Interesting. I live 10 minutes away (by train) from that airport :-)
>
> I take it you'll be at FOSDEM? I'll be giving a talk in the
> IaaS/Virtualization devroom at 14:00 on saturday[1]. If it helps, I'll
> have my laptop with me (and a few cardreaders too, probably); we can
> then debug things face to face if you want me to.
>
> [1] https://fosdem.org/2017/schedule/event/iaas_netblodev/

Yes, I'll be at FOSDEM.  It's good if we can debug things after your
talk.
-- 

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

From: NIIBE Yutaka <gniibe@fsij.org>

To: 854005@bugs.debian.org, Wouter Verhelst <w@uter.be>

Subject: Re: [pkg-gnupg-maint] Bug#854005: Bug#854005: ssh-agent no longer works

Date: Sat, 04 Feb 2017 01:56:08 +0900

NIIBE Yutaka <gniibe@fsij.org> wrote:
> Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC
> is somehow broken in 2.1.18.  Please try with internal CCID driver of
> GnuPG.  I mean, don't use PC/SC service.

Or, please add:

	disable-ccid

in your scdaemon.conf if you want to use PC/SC service with scdaemon of
2.1.18.
-- 

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

From: Wouter Verhelst <w@uter.be>

To: NIIBE Yutaka <gniibe@fsij.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 854005@bugs.debian.org

Subject: Re: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Fri, 3 Feb 2017 21:24:23 +0100

On Sat, Feb 04, 2017 at 01:30:52AM +0900, NIIBE Yutaka wrote:
> Wouter Verhelst <w@uter.be> wrote:
> > wouter@gangtai:~$ cat .gnupg/scdaemon.conf
> > reader-port O2 Micro Oz776 01 00
> > log-file /home/wouter/.gnupg/scdaemon.log
> > pcsc-driver libpcsclite.so
> 
> Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC
> is somehow broken in 2.1.18.  Please try with internal CCID driver of
> GnuPG.  I mean, don't use PC/SC service.

Heh.

I can try if it makes you happy, but I can't use it long-term, or my day
job will become sorely problematic :-)

> >> I'm now at NRT airport to BRU.
> >
> > Interesting. I live 10 minutes away (by train) from that airport :-)
> >
> > I take it you'll be at FOSDEM? I'll be giving a talk in the
> > IaaS/Virtualization devroom at 14:00 on saturday[1]. If it helps, I'll
> > have my laptop with me (and a few cardreaders too, probably); we can
> > then debug things face to face if you want me to.
> >
> > [1] https://fosdem.org/2017/schedule/event/iaas_netblodev/
> 
> Yes, I'll be at FOSDEM.  It's good if we can debug things after your
> talk.

Sure, I'll make sure to have all my stuff so we can look at it in
detail.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

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

From: Wouter Verhelst <w@uter.be>

To: NIIBE Yutaka <gniibe@fsij.org>

Cc: 854005@bugs.debian.org

Subject: Re: [pkg-gnupg-maint] Bug#854005: Bug#854005: ssh-agent no longer works

Date: Fri, 3 Feb 2017 21:27:01 +0100

On Sat, Feb 04, 2017 at 01:56:08AM +0900, NIIBE Yutaka wrote:
> NIIBE Yutaka <gniibe@fsij.org> wrote:
> > Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC
> > is somehow broken in 2.1.18.  Please try with internal CCID driver of
> > GnuPG.  I mean, don't use PC/SC service.
> 
> Or, please add:
> 
> 	disable-ccid
> 
> in your scdaemon.conf if you want to use PC/SC service with scdaemon of
> 2.1.18.

At first glance that doesn't seem to fix it, but I haven't tested it much.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

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

From: Wouter Verhelst <wouter@debian.org>

To: 854005@bugs.debian.org

Subject: workaround

Date: Sat, 4 Feb 2017 15:00:00 +0100

A workaround for this bug is to use

disable-ccid

in scdaemon.conf. gniibe confirmed that the issue is a bug in scdaemon, which
tries to exclusively access the smartcard using direct CCID as well as PC/SC at
the same time (which isn't possible for obvious reasons)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

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

From: Antoine Beaupre <anarcat@orangeseeds.org>

To: NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <wouter@debian.org>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Sat, 4 Feb 2017 12:37:52 -0500

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

On Fri, Feb 03, 2017 at 09:40:35AM +0900, NIIBE Yutaka wrote:
> Hello,
> 
> Thanks to dkg to explicitly CC me.
> 
> On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote:
> > Since a recent upgrade, gnupg-agent no longer finds the authentication
> > (SSH) key on my OpenPGP smartcard:
> >
> > wouter@gangtai:~$ gpg --card-status
> 
> It should be an issue of scdaemon.  For 2.1.18, I added multiple card
> reader support.  This might be a possible cause.  Please let me know, if
> 2.1.17 worked fine or not.

Here I can confirm I was able to access my Yubikey with GnuPG/scdaemon
2.1.17 in Debian stretch fine until the 2.1.18 upgrade. Then it started
to completely fail with:

[996]anarcat@curie:~$ LANG=C gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device

... which is slightly different from the bug report here. The
workaround is the same though,  just adding "disable-ccid" to
.gnupg/scdaemon.conf fixes the problem.

This seems like an important regression, however. If "disable-ccid"
should absolutely be added by users, this should be noted in the
NEWS.Debian file. Alternatively, this should "just work" regardless of
whether it's enabled or not.

Thanks!

a.

PS: the details of my yubikey setup can be found here:

https://anarc.at/blog/2015-12-14-yubikey-howto/

It should be fairly standard, and I added a reference to this bug there.

-- 
The survival of humans and other species on planet Earth in my view can
only be guaranteed via a timely transition towards a stationary
state, a world economy without growth.
                         - Peter Custers

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

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

From: Corey Richardson <corey@octayn.net>

To: 854005@bugs.debian.org

Date: Sat, 4 Feb 2017 17:58:56 -0500

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

I also had a similar issue as anarcat with gpg 2.1.18 and my yubikey neo
with the same symptoms, although I'm running Exherbo, and not Debian.
The disable-ccid workaround in scdaemon.conf worked for me.

--
cmr
http://octayn.net/
+16038524272

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

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

From: Wouter Verhelst <w@uter.be>

To: Antoine Beaupre <anarcat@orangeseeds.org>

Cc: NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Sun, 5 Feb 2017 12:20:38 +0100

So, for clarity,

On Sat, Feb 04, 2017 at 12:37:52PM -0500, Antoine Beaupre wrote:
> This seems like an important regression, however. If "disable-ccid"
> should absolutely be added by users, this should be noted in the
> NEWS.Debian file. Alternatively, this should "just work" regardless of
> whether it's enabled or not.

The problem, as gniibe explained it to me, is that scdaemon tries to
access the card exclusively using *both* direct CCID and PCSC (through
pcscd) at the *same* time. Obviously this can't work.

Therefore, the user has to make a selection, to use either CCID or PCSC.
If the user wants to do the first, then the "pcscd" package should *not*
be installed.

If the user is in my situation, however, where they also need to deal
with other smart card software and pcscd is still required, then they
need to disable CCID, which is done with the "disable-ccid" line in the
scdaemon.conf file.

gniibe suggested that fixing this may be too late before the freeze, and
that the fact that he added multi-cardreader support is an important new
feature that solves many problems at the price of needing some good
documentation about this bug.

I concur; the workaround is relatively easy (choose one option, where
"CCID" is probably the most common and certainly the most tested by the
developers themselves, and disable the other method), and after that the
problem is gone. However, the gnupg package maintainers might want to
think about how to best document this issue.

Regards,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

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

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

To: Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Cc: NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Sun, 05 Feb 2017 16:50:08 -0500

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

On Sun 2017-02-05 06:20:38 -0500, Wouter Verhelst wrote:
> I concur; the workaround is relatively easy (choose one option, where
> "CCID" is probably the most common and certainly the most tested by
> the developers themselves, and disable the other method), and after
> that the problem is gone.

To be concrete, i believe the two proposed solutions for users are:

Do not use PCSC
---------------

Either system-wide:
   
    apt purge pcscd

or per-user:

    echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon
     
Do not use CCID
---------------

    echo disable-ccid:0:1 | gpgconf --change-options scdaemon

> However, the gnupg package maintainers might want to think about how
> to best document this issue.

aiui, CCID is the preferred method for scdaemon to access smartcards.

Would it make sense instead to just change the defaults for pcsc-driver
to be the empty string?

In that case, people who have pcsc-specific devices (that won't be
available via ccid directly) would do:

    printf 'pcsc-driver:0:"libpcsclite.so.1\n' | gpgconf --change-options scdaemon

(this enables both pcsc and ccid, returning to the current default)

And the people who need to use devices that can be used via both
mechanisms (and therefore need to disable ccid) can instead do:

    printf 'pcsc-driver:0:"libpcsclite.so.1\ndisable-ccid:0:1\n' | gpgconf --change-options scdaemon

(this enables pcsc and disables ccid)

gniibe, what do you think of this proposed change to the defaults?

        --dkg

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

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

From: NIIBE Yutaka <gniibe@fsij.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Cc: 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Mon, 06 Feb 2017 15:04:44 +0900

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> To be concrete, i believe the two proposed solutions for users are:
[...]
> Do not use CCID
> ---------------
>
>     echo disable-ccid:0:1 | gpgconf --change-options scdaemon
>

Correct.

The things for PCSC is a bit complicated.  Let me describe.

> Do not use PCSC
> ---------------
>
> Either system-wide:
>    
>     apt purge pcscd

This works.  Actually, this is not mandatory.  It is OK to have pcscd
package installed **if not used**.

The order of usage by scdaemon is:

     (1) First, try internal ccid-driver.
     (2) Then, try PC/SC service.

I enbugged in 2.1.18 and the transition (1)->(2) doesen't work well now.

When pcscd is not running, ccid-driver just works well even if pcscd
package is installed.

Internal ccid-driver fails when pcscd service is running and it tries to
open USB devices which are now under the control of pcscd.

And when pcscd is running on a system,

> or per-user:
>
>     echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon

... this does not work.  A user need to kill pcscd service.

>> However, the gnupg package maintainers might want to think about how
>> to best document this issue.
>
> aiui, CCID is the preferred method for scdaemon to access smartcards.

For GNU/Linux system, yes.  However, there are users (especially in
Eurpoe), who want to use other smcartcards like citizen ID card
simultaneously/interchangeably on a system.  scdaemon is not a system-
wide service for all smartcards, but it's specific to OpenPGP card and
it's per user service for gpg-agent.

> Would it make sense instead to just change the defaults for pcsc-driver
> to be the empty string?

The problem is pcscd holds the access to device, which prevents
ccid-driver's access.

Current order makes some sense.  Specific one first, then catch-all one
second.  However, in future implementation of scdaemon, perhaps,
changing the order of access (pcscd first, ccid-driver second) would
also make sense for some use cases.
-- 

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

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

To: NIIBE Yutaka <gniibe@fsij.org>, Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Cc: 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Mon, 06 Feb 2017 02:13:25 -0500

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

hi gniibe--

thanks for the thoughtful followup!

On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka <gniibe@fsij.org> wrote:
> This works.  Actually, this is not mandatory.  It is OK to have pcscd
> package installed **if not used**.

I take it you mean that the system-wide pcscd service itself needs to be
stopped.

> The order of usage by scdaemon is:
>
>      (1) First, try internal ccid-driver.
>      (2) Then, try PC/SC service.
>
> I enbugged in 2.1.18 and the transition (1)->(2) doesen't work well now.

Are you saying that 2.1.18-4 isn't a sufficient fix for this?  Are there
other patches we should consider applying in debian to smooth this
(1)->(2) transition?

> When pcscd is not running, ccid-driver just works well even if pcscd
> package is installed.
>
> Internal ccid-driver fails when pcscd service is running and it tries to
> open USB devices which are now under the control of pcscd.
>
> And when pcscd is running on a system,
>
>> or per-user:
>>
>>     echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon
>
> ... this does not work.  A user need to kill pcscd service.

This is because the pcscd service itself will be locking the card in an
exclusive fashion, right?

> For GNU/Linux system, yes.  However, there are users (especially in
> Eurpoe), who want to use other smcartcards like citizen ID card
> simultaneously/interchangeably on a system.  scdaemon is not a system-
> wide service for all smartcards, but it's specific to OpenPGP card and
> it's per user service for gpg-agent.

Would it work for the user to tell pcscd to explicitly ignore certain
devices that are expected to be handled only by scdaemon?  that would
allow pcscd to run and serve the non-OpenPGP cards, while allowing
scdaemon to do its work with the OpenPGP cards.

I'm not suggesting that this would be particularly easy (or even
possible, in some cases) to configure, but i'm just trying to explore
the space of options for users.

This should really all be much easier, sigh :(

>> Would it make sense instead to just change the defaults for pcsc-driver
>> to be the empty string?
>
> The problem is pcscd holds the access to device, which prevents
> ccid-driver's access.
>
> Current order makes some sense.  Specific one first, then catch-all one
> second.  However, in future implementation of scdaemon, perhaps,
> changing the order of access (pcscd first, ccid-driver second) would
> also make sense for some use cases.

so many options!  and yet users generally just want things to Just Work™
:/

Do you want to propose any documentation or notes about this situation?
README.Debian, or something else?

Thanks for your work on this,

       --dkg

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

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

From: Wouter Verhelst <w@uter.be>

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

Cc: NIIBE Yutaka <gniibe@fsij.org>, Antoine Beaupre <anarcat@orangeseeds.org>, 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Mon, 6 Feb 2017 12:40:07 +0100

On Mon, Feb 06, 2017 at 02:13:25AM -0500, Daniel Kahn Gillmor wrote:
> On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka <gniibe@fsij.org> wrote:
> > This works.  Actually, this is not mandatory.  It is OK to have pcscd
> > package installed **if not used**.
> 
> I take it you mean that the system-wide pcscd service itself needs to be
> stopped.

Actually, no, because due to systemd and socket activation having it installed
is enough to make it start ;-)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

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

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

To: Wouter Verhelst <w@uter.be>

Cc: NIIBE Yutaka <gniibe@fsij.org>, Antoine Beaupre <anarcat@orangeseeds.org>, 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Mon, 06 Feb 2017 10:15:46 -0500

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

On Mon 2017-02-06 06:40:07 -0500, Wouter Verhelst wrote:
> On Mon, Feb 06, 2017 at 02:13:25AM -0500, Daniel Kahn Gillmor wrote:
>> On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka <gniibe@fsij.org> wrote:
>> > This works.  Actually, this is not mandatory.  It is OK to have pcscd
>> > package installed **if not used**.
>> 
>> I take it you mean that the system-wide pcscd service itself needs to be
>> stopped.
>
> Actually, no, because due to systemd and socket activation having it installed
> is enough to make it start ;-)

OK, let's try that again:

I take it you mean that the the system-wide pcscd service itself needs
to be disabled and prevented from being started again:

     systemctl disable --now pcscd.socket pcscd.service


thanks for the clarification ;)

       --dkg

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

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

From: NIIBE Yutaka <gniibe@fsij.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Cc: 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Tue, 07 Feb 2017 04:39:34 +0900

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka <gniibe@fsij.org> wrote:
>> This works.  Actually, this is not mandatory.  It is OK to have pcscd
>> package installed **if not used**.
>
> I take it you mean that the system-wide pcscd service itself needs to be
> stopped.

In another message:
> I take it you mean that the the system-wide pcscd service itself needs
> to be disabled and prevented from being started again:
> 
>      systemctl disable --now pcscd.socket pcscd.service

No.  It is OK systemd watches the socket to invoke pcscd.service, as
long as no client tries to connect the socket (by libpcsclite.so.1.0.0).

>> The order of usage by scdaemon is:
>>
>>      (1) First, try internal ccid-driver.
>>      (2) Then, try PC/SC service.
>>
>> I enbugged in 2.1.18 and the transition (1)->(2) doesen't work well now.
>
> Are you saying that 2.1.18-4 isn't a sufficient fix for this?  Are there
> other patches we should consider applying in debian to smooth this
> (1)->(2) transition?

No, 2.1.18-4 (or even master in upstream) is not a sufficient fix.  I
don't have an idea of any good solution at hand, yet.  Thus, workaround
of "disable-ccid".

>>> or per-user:
>>>
>>>     echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon
>>
>> ... this does not work.  A user need to kill pcscd service.
>
> This is because the pcscd service itself will be locking the card in an
> exclusive fashion, right?

Let me clarify.  It is not the problem of locking of the card, but
problem of which process is using USB device.  Only a single process can
claim an interface of a USB device at given time.  And pcscd serves all
CCID devices to client(s).

Upon initialization of pcscd, pcscd claims all CCID devices (= card
readers).  Then, it starts accepting request from clients.  A client 
asks list of card readers, and then connects to a card reader.  For
PC/SC service, it is possible for client to access a card in shared
fashon or exclusive fashion.

Once pcscd is invoked, all CCID devices are under control of pcscd, even
if there are no client.

>> For GNU/Linux system, yes.  However, there are users (especially in
>> Eurpoe), who want to use other smcartcards like citizen ID card
>> simultaneously/interchangeably on a system.  scdaemon is not a system-
>> wide service for all smartcards, but it's specific to OpenPGP card and
>> it's per user service for gpg-agent.
>
> Would it work for the user to tell pcscd to explicitly ignore certain
> devices that are expected to be handled only by scdaemon?  that would
> allow pcscd to run and serve the non-OpenPGP cards, while allowing
> scdaemon to do its work with the OpenPGP cards.

In some use cases, this would be possible;  Say, Yubikey and Nitrokey
are handled only by scdaemon through its CCID driver.

The other use case is: some users want to use a single card reader for
both of OpenPGP card and non-OpenPGP card, interchangeably.

> I'm not suggesting that this would be particularly easy (or even
> possible, in some cases) to configure, but i'm just trying to explore
> the space of options for users.
>
> This should really all be much easier, sigh :(
>
>>> Would it make sense instead to just change the defaults for pcsc-driver
>>> to be the empty string?
>>
>> The problem is pcscd holds the access to device, which prevents
>> ccid-driver's access.
>>
>> Current order makes some sense.  Specific one first, then catch-all one
>> second.  However, in future implementation of scdaemon, perhaps,
>> changing the order of access (pcscd first, ccid-driver second) would
>> also make sense for some use cases.
>
> so many options!  and yet users generally just want things to Just Work™
> :/
>
> Do you want to propose any documentation or notes about this situation?
> README.Debian, or something else?

I think that an explanation like following is good.

	If you want to use PC/SC service, please add 

	    disable-ccid

        in .gnupg/scdaemon.conf.  Or do:

	    echo disable-ccid:0:1 | gpgconf --change-options scdaemon
-- 

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

From: Antoine Beaupré <anarcat@debian.org>

To: NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <wouter@debian.org>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Mon, 06 Feb 2017 19:55:58 -0500

the daemon stopped working again - even with disable-ccid:

$ LANG=C gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device

i got a different error now:

fév 06 19:45:29 curie gpg-agent[1643]: gpg-agent (GnuPG) 2.1.18 starting in supervised mode. 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 3 for std socket (/run/user/1000/gnupg/S.gpg-agent) 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 4 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh) 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 5 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra) 
fév 06 19:45:29 curie gpg-agent[1643]: using fd 6 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser) 
fév 06 19:45:29 curie gpg-agent[1643]: listening on: std=3 extra=5 browser=6 ssh=4 
fév 06 19:45:29 curie gpg-agent[1643]: scdaemon[1645] pcsc_establish_context failed: no service (0x8010001d) 

pcsc_establish_context failed: no service (0x8010001d) 

This is strange, because there hasn't been a change in the gpg software
since my last report, and I *thought* I had this fixed with the ccid
workaround. But it seems that doesn't work anymore. :(

I have tried uninstalling pcscd, running the command again, same result.

Now the oddest thing is - installing pcscd again fixed the problem.

No idea what's going on here.

A.
-- 
Il n'existe aucune limite sacrée ou non à l'action de l'homme dans
l'univers. Depuis nos origines nous avons le choix: être aveuglé par
la vérité ou coudre nos paupières.
                        - [no one is innocent]

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

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

To: NIIBE Yutaka <gniibe@fsij.org>, Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Cc: 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Mon, 06 Feb 2017 22:57:59 -0500

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

On Mon 2017-02-06 14:39:34 -0500, NIIBE Yutaka wrote:
> I think that an explanation like following is good.
>
> 	If you want to use PC/SC service, please add 
>
> 	    disable-ccid
>
>         in .gnupg/scdaemon.conf.  Or do:
>
> 	    echo disable-ccid:0:1 | gpgconf --change-options scdaemon


My only concern with this explanation is that most people (even those
with smartcards!) have *no*idea* whether they "want to use PC/SC
service."  They just bought a smartcard (or were given one by their
employer or their government or their friend or whatever) and they know
they're supposed to use it.

Can we offer a user experience that doesn't involve them making a choice
between two indistinguishable options?

A few ideas (no idea how plausible they are to implement, or even
whether they'd solve the problems people are having):

 0) if pcscd is running and has claimed the smartcard, then by default
    disable ccid?

 1) for each device that is detected by ccid, try to access it.  If it
    is not accessible because someone else has it locked, and pcscd
    appears to be running, and a similar-looking device is accessible
    through pcsc, then skip the device entirely without complaint.

 2) revert whatever the change was in 2.1.18 (handling multiple cards?)
    that made things worse for people who had things working in 2.1.17

Any other suggestions?

Thanks for looking into this, gniibe!  Sorry if it's frustrating, but
your expertise in thinking through these issues is very much
appreciated.

     --dkg

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

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

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

To: Antoine Beaupré <anarcat@debian.org>, NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org

Cc: Wouter Verhelst <wouter@debian.org>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Mon, 06 Feb 2017 23:01:16 -0500

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

On Mon 2017-02-06 19:55:58 -0500, Antoine Beaupré wrote:
> the daemon stopped working again - even with disable-ccid:
>
> $ LANG=C gpg --card-status
> gpg: selecting openpgp failed: No such device
> gpg: OpenPGP card not available: No such device
>
> i got a different error now:
>
> fév 06 19:45:29 curie gpg-agent[1643]: gpg-agent (GnuPG) 2.1.18 starting in supervised mode. 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 3 for std socket (/run/user/1000/gnupg/S.gpg-agent) 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 4 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh) 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 5 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra) 
> fév 06 19:45:29 curie gpg-agent[1643]: using fd 6 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser) 
> fév 06 19:45:29 curie gpg-agent[1643]: listening on: std=3 extra=5 browser=6 ssh=4 
> fév 06 19:45:29 curie gpg-agent[1643]: scdaemon[1645] pcsc_establish_context failed: no service (0x8010001d) 
>
> pcsc_establish_context failed: no service (0x8010001d) 
>
> This is strange, because there hasn't been a change in the gpg software
> since my last report, and I *thought* I had this fixed with the ccid
> workaround. But it seems that doesn't work anymore. :(
>
> I have tried uninstalling pcscd, running the command again, same result.
>
> Now the oddest thing is - installing pcscd again fixed the problem.
>
> No idea what's going on here.

This sounds to me like pcscd crashed or otherwise terminated.

afaict, the two options are:

 * pcsc
 * ccid

the workaround i've seen mooted here of "disable-ccid" means that all
your eggs are in the pcsc basket.  If pcscd fails or drops the card or
whatever, then scdaemon can't fall back to ccid.

did you have disable-ccid set in scdaemon.conf?

does this line of thinking make sense?

     --dkg

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

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

From: NIIBE Yutaka <gniibe@fsij.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Cc: 854005@bugs.debian.org

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Tue, 07 Feb 2017 15:17:04 +0900

Hello,

Thank you very much for the discussion.  I appreciate the viewpoints
from users.  No, it's not frustrating at all.

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> Can we offer a user experience that doesn't involve them making a choice
> between two indistinguishable options?
>
> A few ideas (no idea how plausible they are to implement, or even
> whether they'd solve the problems people are having):
>
>  0) if pcscd is running and has claimed the smartcard, then by default
>     disable ccid?
>
>  1) for each device that is detected by ccid, try to access it.  If it
>     is not accessible because someone else has it locked, and pcscd
>     appears to be running, and a similar-looking device is accessible
>     through pcsc, then skip the device entirely without complaint.
>
>  2) revert whatever the change was in 2.1.18 (handling multiple cards?)
>     that made things worse for people who had things working in 2.1.17
>
> Any other suggestions?

2) would be easy choice if any breaking is considered bad and that's the
highest priority.  I am sorry that I break this use case on GNU/Linux.
I thought I tested carefully, but my test coverage is apparently not
that large, I learned.

On GNU/Linux, use of PC/SC service is not recommended for OpenPGP card
(installing PC/SC is OK) and the use of different smartcards with PC/SC
(OpenPGP card together with other cards) requires struggle anyway, so, I
think that asking such users would be an option.

No, I don't say I won't fix this issue.  Surely, I will.

Currently, I am considering something like 1).



Some more information, from here.  Please skip.

> My only concern with this explanation is that most people (even those
> with smartcards!) have *no*idea* whether they "want to use PC/SC
> service."  They just bought a smartcard (or were given one by their
> employer or their government or their friend or whatever) and they know
> they're supposed to use it.

Yes.  This is an important point.

Unfortunately, I think that current situation of use of OpenPGP card is
somehow far from this.  Let me explain.

The situation is complicated becase only some limited card readers works
for OpenPGP card.  Since most users prefer longer key size of RSA these
days, the use of OpenPGP card requires tough condition to card reader.
Some workaround in the lower level of USB communcation for specific card
readers are implemented in the internal CCID driver, so, if the use if
for OpenPGP card, internal CCID driver is better option.

Please note that this is common:

    A card reader itself works well on the machine, but OpenPGP card
    with (common configuration of) RSA-4096 doesn't work with a reader.
    While --card-status works, decryption fails.

I think that something like this is common problem in smartcard
industry.  Current industrial practice seems to be a smartcard requires
specific card reader and vendor's offering application specific driver
which doesn't use general purpose PC/SC service.  Ideally, such
fragmentation should be avoided and it would be better to put all
lower-level knowledge/workaround to PC/SC service, so that all
application can be share common ground.  But it seems going
another direction.

Perhaps, card + reader can not be abstracted well.


And I think that there are two distinct use cases.

(1) Smartcard is given by external entity to user.  He has a little
    interest in detail.  The purpose is "just use it".

(2) User cares a lot on her privacy, and that is the reason why she
    starts to use smartcard.

It would make sense to put priority to the use case of (1), because
there are more users in this situation.  And since PC/SC serivice tries
to support more card readers, which are listed in
/etc/libccid_Info.plist, it might be a natural choice for a user in this
situation to prefer PC/SC even if he only uses OpenPGP card.

I agree that it is best if we don't need to ask users of (1) to put
"disable-ccid" in his configuration file.  So, I will try, but I don't
have a good solution at hand, right now.

Please note that current default of scdaemon is for the use case of (2).
And I recommend use of the internal CCID driver, a dedicated card reader
access implementation specific to OpenPGP card.  For the readers which
are listed in /lib/udev/rules.d/60-scdaemon.rules, it is easy to use (I
mean, no other configuration needed).  But user needs her own udev rules
if her reader is not listed there.
-- 

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

From: Werner Koch <wk@gnupg.org>

To: NIIBE Yutaka <gniibe@fsij.org>

Cc: 854005@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Subject: Re: [pkg-gnupg-maint] Bug#854005: Bug#854005: ssh-agent no longer works

Date: Tue, 07 Feb 2017 08:51:17 +0100

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

On Mon,  6 Feb 2017 07:04, gniibe@fsij.org said:
> simultaneously/interchangeably on a system.  scdaemon is not a system-
> wide service for all smartcards, but it's specific to OpenPGP card and
> it's per user service for gpg-agent.

FWIW: Scdaemon supports several smartcards and certain other cards than
the OpenPGP card are in active use (in particular for S/MIME).  However,
scdaemon does not make use of any "middleware" commonly seen with these
cards.


Shalom-Salam,

   Werner

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

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

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

From: Antoine Beaupré <anarcat@debian.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org

Cc: Wouter Verhelst <wouter@debian.org>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Tue, 07 Feb 2017 09:28:33 -0500

On 2017-02-06 23:01:16, Daniel Kahn Gillmor wrote:
> On Mon 2017-02-06 19:55:58 -0500, Antoine Beaupré wrote:
>> the daemon stopped working again - even with disable-ccid:
>>
>> $ LANG=C gpg --card-status
>> gpg: selecting openpgp failed: No such device
>> gpg: OpenPGP card not available: No such device
>>
>> i got a different error now:
>>
>> fév 06 19:45:29 curie gpg-agent[1643]: gpg-agent (GnuPG) 2.1.18 starting in supervised mode. 
>> fév 06 19:45:29 curie gpg-agent[1643]: using fd 3 for std socket (/run/user/1000/gnupg/S.gpg-agent) 
>> fév 06 19:45:29 curie gpg-agent[1643]: using fd 4 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh) 
>> fév 06 19:45:29 curie gpg-agent[1643]: using fd 5 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra) 
>> fév 06 19:45:29 curie gpg-agent[1643]: using fd 6 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser) 
>> fév 06 19:45:29 curie gpg-agent[1643]: listening on: std=3 extra=5 browser=6 ssh=4 
>> fév 06 19:45:29 curie gpg-agent[1643]: scdaemon[1645] pcsc_establish_context failed: no service (0x8010001d) 
>>
>> pcsc_establish_context failed: no service (0x8010001d) 
>>
>> This is strange, because there hasn't been a change in the gpg software
>> since my last report, and I *thought* I had this fixed with the ccid
>> workaround. But it seems that doesn't work anymore. :(
>>
>> I have tried uninstalling pcscd, running the command again, same result.
>>
>> Now the oddest thing is - installing pcscd again fixed the problem.
>>
>> No idea what's going on here.
>
> This sounds to me like pcscd crashed or otherwise terminated.
>
> afaict, the two options are:
>
>  * pcsc
>  * ccid
>
> the workaround i've seen mooted here of "disable-ccid" means that all
> your eggs are in the pcsc basket.  If pcscd fails or drops the card or
> whatever, then scdaemon can't fall back to ccid.
>
> did you have disable-ccid set in scdaemon.conf?

yes, i did.

> does this line of thinking make sense?

yes, it makes sense. i'll try to figure out if pcscd had crashed - but I
don't understand how reinstalling the package could have possibly fixed
this.

a.

-- 
The destiny of Earthseed is to take root among the stars.
                        - Octavia Butler

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

From: Antoine Beaupré <anarcat@debian.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org

Cc: Wouter Verhelst <wouter@debian.org>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Wed, 08 Feb 2017 10:24:59 -0500

On 2017-02-07 09:28:33, Antoine Beaupré wrote:
>> does this line of thinking make sense?
>
> yes, it makes sense. i'll try to figure out if pcscd had crashed - but I
> don't understand how reinstalling the package could have possibly fixed
> this.

so here's what i could find. my first (traumatic) finding is that pcscd
runs as root... i was trying to find it in my process tree and failing
because of that, so that's part of the confusion.

this is the reason why removing the package fixes the issue - it
probably resets the systemd configuration for the daemon and
reinstalling restarts it properly.

now it is running - but who knows for how long?

● pcscd.service - PC/SC Smart Card Daemon
   Loaded: loaded (/lib/systemd/system/pcscd.service; indirect; vendor preset: enabled)
   Active: active (running) since Wed 2017-02-08 10:12:36 EST; 4min 1s ago
 Main PID: 14439 (pcscd)
   CGroup: /system.slice/pcscd.service
           └─14439 /usr/sbin/pcscd --foreground --auto-exit

It seems that I need to do this reset thing every morning now, so I
guess it's crashing at least every 24 hours. i have tried unplugging and
replugging the yubikey, it doesn't trigger the problem.

i have tried to figure out what may have happened by looking at the
journald logs, but i can't figure it out. it doesn't clearly mention a
crash. 

notice, in the log below, that i reinstalled the package at around Feb
08 10:12:36, which is when things went back to normal. yet before that,
it's unclear if there was a problem.

any ideas? should this be a separate bug report? it doesn't *look* like
it's the same issue because the workaround fails...

thanks,

a.

-- 
The steel horse fills a gap in modern life, it is an answer not only to
its needs, but also to its aspirations.  It's quite certainly here to
stay.
                         - Le Vélocipède Illustré, 1869

$ sudo LANG=C journalctl -x -u pcscd.service
-- Logs begin at Sat 2017-02-04 11:17:15 EST, end at Wed 2017-02-08 10:19:46 EST. --
Feb 04 12:33:58 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 04 12:33:58 curie pcscd[8947]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 04 12:33:58 curie pcscd[8947]: 00000012 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/007)
Feb 04 12:33:58 curie pcscd[8947]: 00000002 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 04 12:33:58 curie pcscd[8947]: 00341712 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 04 12:44:42 curie pcscd[8947]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 04 12:44:45 curie pcscd[8947]: 03512295 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 04 13:26:51 curie pcscd[8947]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/7): -4 LIBUSB_ERROR_NO_DEVICE
Feb 04 17:28:58 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 04 17:29:16 curie pcscd[31517]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 04 17:29:16 curie pcscd[31517]: 00000014 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/008)
Feb 04 17:29:16 curie pcscd[31517]: 00000003 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 04 17:53:08 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 04 17:53:08 curie pcscd[1915]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 04 17:53:08 curie pcscd[1915]: 00000018 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/008)
Feb 04 17:53:08 curie pcscd[1915]: 00000002 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 04 17:53:09 curie pcscd[1915]: 00860385 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 04 18:10:35 curie pcscd[1915]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 04 18:27:49 curie pcscd[1915]: 99999999 ccid_usb.c:1337:InterruptStop() libusb_cancel_transfer failed: -4
Feb 04 18:27:49 curie pcscd[1915]: 00400400 ccid_usb.c:797:WriteUSB() write failed (1/8): -4 LIBUSB_ERROR_NO_DEVICE
Feb 06 10:55:09 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 06 10:55:09 curie pcscd[20263]: 00000000 utils.c:82:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory
Feb 06 10:55:09 curie pcscd[20263]: 00007301 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 06 10:55:09 curie pcscd[20263]: 00000009 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/010)
Feb 06 10:55:09 curie pcscd[20263]: 00000003 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 06 11:07:17 curie pcscd[20263]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 12:13:37 curie pcscd[20263]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 12:13:52 curie pcscd[20263]: 15281542 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 18:27:32 curie pcscd[20263]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/10): -4 LIBUSB_ERROR_NO_DEVICE
Feb 06 19:48:27 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 06 19:48:27 curie pcscd[3100]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 06 19:48:27 curie pcscd[3100]: 00000014 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/013)
Feb 06 19:48:27 curie pcscd[3100]: 00000003 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 06 19:48:49 curie pcscd[3100]: 22045135 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:49:15 curie pcscd[3100]: 26297901 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:49:56 curie pcscd[3100]: 41260039 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:50:06 curie pcscd[3100]: 09673127 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:51:25 curie pcscd[3100]: 78500770 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 20:22:55 curie pcscd[3100]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 20:23:00 curie pcscd[3100]: 04869977 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 20:30:37 curie pcscd[3100]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/13): -4 LIBUSB_ERROR_NO_DEVICE
Feb 07 20:55:56 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 07 20:55:56 curie pcscd[21376]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 07 20:55:56 curie pcscd[21376]: 00000012 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/015)
Feb 07 20:55:56 curie pcscd[21376]: 00000004 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 07 20:56:02 curie pcscd[21376]: 05648900 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 20:56:12 curie pcscd[21376]: 09655699 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 20:56:36 curie pcscd[21376]: 24217358 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 21:06:59 curie pcscd[21376]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 21:08:03 curie pcscd[21376]: 63425592 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 22:01:33 curie pcscd[21376]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 22:27:31 curie pcscd[21376]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/15): -4 LIBUSB_ERROR_NO_DEVICE
Feb 08 10:12:36 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 08 10:12:36 curie pcscd[14439]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 08 10:12:36 curie pcscd[14439]: 00000014 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/016)
Feb 08 10:12:36 curie pcscd[14439]: 00000003 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 08 10:13:10 curie pcscd[14439]: 33826818 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 08 10:17:53 curie pcscd[14439]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/16): -4 LIBUSB_ERROR_NO_DEVICE
Feb 08 10:17:58 curie pcscd[14439]: 04993454 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 08 10:17:58 curie pcscd[14439]: 00000012 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/017)
Feb 08 10:17:58 curie pcscd[14439]: 00000004 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 08 10:18:11 curie pcscd[14439]: 12507788 winscard.c:283:SCardConnect() Error Reader Exclusive
...skipping...
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 06 19:48:27 curie pcscd[3100]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 06 19:48:27 curie pcscd[3100]: 00000014 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/013)
Feb 06 19:48:27 curie pcscd[3100]: 00000003 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 06 19:48:49 curie pcscd[3100]: 22045135 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:49:15 curie pcscd[3100]: 26297901 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:49:56 curie pcscd[3100]: 41260039 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:50:06 curie pcscd[3100]: 09673127 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 19:51:25 curie pcscd[3100]: 78500770 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 20:22:55 curie pcscd[3100]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 20:23:00 curie pcscd[3100]: 04869977 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 06 20:30:37 curie pcscd[3100]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/13): -4 LIBUSB_ERROR_NO_DEVICE
Feb 07 20:55:56 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 07 20:55:56 curie pcscd[21376]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 07 20:55:56 curie pcscd[21376]: 00000012 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/015)
Feb 07 20:55:56 curie pcscd[21376]: 00000004 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 07 20:56:02 curie pcscd[21376]: 05648900 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 20:56:12 curie pcscd[21376]: 09655699 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 20:56:36 curie pcscd[21376]: 24217358 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 21:06:59 curie pcscd[21376]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 21:08:03 curie pcscd[21376]: 63425592 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 22:01:33 curie pcscd[21376]: 99999999 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 07 22:27:31 curie pcscd[21376]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/15): -4 LIBUSB_ERROR_NO_DEVICE
Feb 08 10:12:36 curie systemd[1]: Started PC/SC Smart Card Daemon.
-- Subject: Unit pcscd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit pcscd.service has finished starting up.
-- 
-- The start-up result is done.
Feb 08 10:12:36 curie pcscd[14439]: 00000000 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 08 10:12:36 curie pcscd[14439]: 00000014 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/016)
Feb 08 10:12:36 curie pcscd[14439]: 00000003 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 08 10:13:10 curie pcscd[14439]: 33826818 winscard.c:283:SCardConnect() Error Reader Exclusive
Feb 08 10:17:53 curie pcscd[14439]: 99999999 ccid_usb.c:797:WriteUSB() write failed (1/16): -4 LIBUSB_ERROR_NO_DEVICE
Feb 08 10:17:58 curie pcscd[14439]: 04993454 ifdhandler.c:151:CreateChannelByNameOrChannel() failed
Feb 08 10:17:58 curie pcscd[14439]: 00000012 readerfactory.c:1110:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0111:libudev:0:/dev/bus/usb/001/017)
Feb 08 10:17:58 curie pcscd[14439]: 00000004 readerfactory.c:375:RFAddReader() Yubico Yubikey NEO OTP+CCID init failed.
Feb 08 10:18:11 curie pcscd[14439]: 12507788 winscard.c:283:SCardConnect() Error Reader Exclusive

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

From: Antoine Beaupré <anarcat@debian.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, NIIBE Yutaka <gniibe@fsij.org>, 854005@bugs.debian.org

Cc: Wouter Verhelst <wouter@debian.org>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Wed, 08 Feb 2017 12:37:25 -0500

On 2017-02-08 10:24:59, Antoine Beaupré wrote:
> any ideas? should this be a separate bug report? it doesn't *look* like
> it's the same issue because the workaround fails...

i have filed a separate bug report against scdaemon regarding this, to
see if we can make it work without pcscd (it doesn't here).

there could be a separate bug report to file about pcscd crashing, but i
have yet to get clear confirmation on that. that may happen tomorrow as
i go back to my regular "wtf why isn't the yubikey working now"
thing. :p

a.
-- 
Drowning people
Sometimes die
Fighting their rescuers.
                        - Octavia Butler

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

From: Ludovic Rousseau <ludovic.rousseau@free.fr>

To: 854005@bugs.debian.org, NIIBE Yutaka <gniibe@fsij.org>, Werner Koch <wk@gnupg.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Wouter Verhelst <w@uter.be>, Antoine Beaupre <anarcat@orangeseeds.org>

Subject: Re: Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

Date: Fri, 10 Feb 2017 19:11:17 +0100

On Tue, 07 Feb 2017 15:17:04 +0900 NIIBE Yutaka <gniibe@fsij.org> wrote:
> Hello,

Hello,
 
> On GNU/Linux, use of PC/SC service is not recommended for OpenPGP card

Why is that exactly?

> (installing PC/SC is OK) and the use of different smartcards with PC/SC
> (OpenPGP card together with other cards) requires struggle anyway, so, I
> think that asking such users would be an option.

My proposal:

- if "disable-ccid" is present then use PC/SC
- if "disable-ccid" is not present then use the internal CCID only and do not use PC/SC

The default value would be to use "disable-ccid".

People that _really_ know what they do could remove the "disable-ccid" (and break PC/SC).

> The situation is complicated becase only some limited card readers works
> for OpenPGP card.  Since most users prefer longer key size of RSA these
> days, the use of OpenPGP card requires tough condition to card reader.
> Some workaround in the lower level of USB communcation for specific card
> readers are implemented in the internal CCID driver, so, if the use if
> for OpenPGP card, internal CCID driver is better option.

Use of long RSA keys require extended APDU. Not all smart card readers support extended APDU.
See https://pcsclite.alioth.debian.org/ccid_extended_apdu.html and https://ludovicrousseau.blogspot.fr/2011/05/extended-apdu-status-per-reader.html

Bye

-- 
Dr. Ludovic Rousseau

Message #146 received at 854005-submitter@bugs.debian.org (full text, mbox, reply):

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

To: 854005-submitter@bugs.debian.org

Subject: Bug#854005 marked as pending

Date: Mon, 13 Feb 2017 15:01:01 +0000

tag 854005 pending
thanks

Hello,

Bug #854005 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    http://git.debian.org/?p=pkg-gnupg/gnupg2.git;a=commitdiff;h=4c91bae

---
commit 4c91bae777022f7ffd2ac4fa69837d59653eeb8f
Author: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date:   Mon Feb 13 09:41:56 2017 -0500

    prepare new debian release

diff --git a/debian/changelog b/debian/changelog
index edd953b..bca7302 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+gnupg2 (2.1.18-5) unstable; urgency=medium
+
+  [ Daniel Kahn Gillmor ]
+  * Xsession.d/90gpg-agent: use simpler and more direct gpgconf
+    invocations for socket names.
+
+  [ NIIBE Yutaka ]
+  * scdaemon.udev: Add Yubikey and Nitrokey (Closes: #648331, 734889).
+  * scdaemon fix for PC/SC (Closes: #852702, #854005, #854595, #854616).
+
+ -- Daniel Kahn Gillmor <dkg@fifthhorseman.net>  Mon, 13 Feb 2017 09:15:07 -0500
+
 gnupg2 (2.1.18-4) unstable; urgency=medium
 
   [ Daniel Kahn Gillmor ]

Message #147 received at 852702-close@bugs.debian.org (full text, mbox, reply):

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

To: 852702-close@bugs.debian.org

Subject: Bug#852702: fixed in gnupg2 2.1.18-5

Date: Mon, 13 Feb 2017 15:18:52 +0000

Source: gnupg2
Source-Version: 2.1.18-5

We believe that the bug you reported is fixed in the latest version of
gnupg2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 852702@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Kahn Gillmor <dkg@fifthhorseman.net> (supplier of updated gnupg2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 13 Feb 2017 09:15:07 -0500
Source: gnupg2
Binary: gnupg-agent scdaemon gpgsm gnupg gnupg2 gpgv gpgv2 dirmngr gpgv-udeb gpgv-static gpgv-win32 gnupg-l10n
Architecture: source
Version: 2.1.18-5
Distribution: unstable
Urgency: medium
Maintainer: Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org>
Changed-By: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Description:
 dirmngr    - GNU privacy guard - network certificate management service
 gnupg      - GNU privacy guard - a free PGP replacement
 gnupg-agent - GNU privacy guard - cryptographic agent
 gnupg-l10n - GNU privacy guard - localization files
 gnupg2     - GNU privacy guard - a free PGP replacement (dummy transitional pa
 gpgsm      - GNU privacy guard - S/MIME version
 gpgv       - GNU privacy guard - signature verification tool
 gpgv-static - minimal signature verification tool (static build)
 gpgv-udeb  - minimal signature verification tool (udeb)
 gpgv-win32 - GNU privacy guard - signature verification tool (win32 build)
 gpgv2      - GNU privacy guard - signature verification tool (dummy transition
 scdaemon   - GNU privacy guard - smart card support
Closes: 648331 734889 852702 854005 854595 854616
Changes:
 gnupg2 (2.1.18-5) unstable; urgency=medium
 .
   [ Daniel Kahn Gillmor ]
   * Xsession.d/90gpg-agent: use simpler and more direct gpgconf
     invocations for socket names.
 .
   [ NIIBE Yutaka ]
   * scdaemon.udev: Add Yubikey and Nitrokey (Closes: #648331, 734889).
   * scdaemon fix for PC/SC (Closes: #852702, #854005, #854595, #854616).
Checksums-Sha1:
 7107ae53a9a7b92c96abd2189b34a0d9cd1fba99 3148 gnupg2_2.1.18-5.dsc
 b31b7f97466e99c49c4eb9320b6df12d32d87e78 67321 gnupg2_2.1.18-5.debian.tar.bz2
 a1c521fc8bf43272c59490065eef86cecf06821d 9975 gnupg2_2.1.18-5_source.buildinfo
Checksums-Sha256:
 8eb4d1d8bb97ac770e8f50e558046981fd6f1fea169ae5e74ac959a6d033a35d 3148 gnupg2_2.1.18-5.dsc
 e6dbc03c9a163baff078a47b0f7c023d8b830f80bf6ae486e6a580fbdb71d9c2 67321 gnupg2_2.1.18-5.debian.tar.bz2
 e24155aeaccd93a834ace33df252d57538679afff471235bb770af4140365ec8 9975 gnupg2_2.1.18-5_source.buildinfo
Files:
 cffe62364ca47384f8347317a5d1a673 3148 utils optional gnupg2_2.1.18-5.dsc
 950b349fb8ed2ee14a00155da3ae2650 67321 utils optional gnupg2_2.1.18-5.debian.tar.bz2
 f39a698baf6d532deab22cb867f3a4b3 9975 utils optional gnupg2_2.1.18-5_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJKBAEBCgA0FiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlihyfYWHGRrZ0BmaWZ0
aGhvcnNlbWFuLm5ldAAKCRAUmK3GwZIyN9UvD/0aFI/Jphk4kTyJC/bx5G7vcgpu
pPCrtlb5/FDvko1XJUMohcS8dFuMf7PPHpQZH31kjqawbQMSzVYhXy9wZL6r+hrg
xz68kJ1CgCTFO/HB+h1dTLASt4OuVGfKGpkuueXenR3kCY7Ghx8H6YOlhYRMtVT6
yWhdpGKHIvR82sCLN61iqMut3NTh47MB1QUmWd1zQPNoGPWLBK2dt7hNvqQWvFZ4
XXsGkjk6LQrZegX4JIrAEjsqIjXQlKJhOWnCA4+86EIVbjnUaYjZKX7q2dHOG21Y
DxT6rn4qx9PCMTR5krJPht4R1hbc6C0aZT4y3I6Cp53FS3uZGD84YxGYND9v5WSb
auu5FGwE0xN+RAbHOVTxh0lIuySJJTkIdX78kqsnuaSaNkXCfgiNo3xacs9uY+9d
TYKg17ouRsbnETkVqpDngTaaaY9pK6ajk/u3uyA3znEWp870ww/7gvrMjCl1gkfP
hinmFseLTKOvHQFlDAZb6HTj/V7SXqSr25hMpSoWNXC8ylypfh90fnDD+YNpFXMm
VND3eZTNtW/EEQTxiWVbDrWXFoIrFTioRHLlbH4rC3dkJ0RjxeMiKcKPzrap/5ht
6vu/nqkBgltt/8UPIctb+6Qe5czMFDJj8T+B/m3+sarCzjd4njHcn0Og4H4flvqY
M07IRiEkzX00kH824A==
=fpGR
-----END PGP SIGNATURE-----

Message #152 received at 854005-close@bugs.debian.org (full text, mbox, reply):

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

To: 854005-close@bugs.debian.org

Subject: Bug#854005: fixed in gnupg2 2.1.18-5

Date: Mon, 13 Feb 2017 15:18:52 +0000

Source: gnupg2
Source-Version: 2.1.18-5

We believe that the bug you reported is fixed in the latest version of
gnupg2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 854005@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Kahn Gillmor <dkg@fifthhorseman.net> (supplier of updated gnupg2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 13 Feb 2017 09:15:07 -0500
Source: gnupg2
Binary: gnupg-agent scdaemon gpgsm gnupg gnupg2 gpgv gpgv2 dirmngr gpgv-udeb gpgv-static gpgv-win32 gnupg-l10n
Architecture: source
Version: 2.1.18-5
Distribution: unstable
Urgency: medium
Maintainer: Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org>
Changed-By: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Description:
 dirmngr    - GNU privacy guard - network certificate management service
 gnupg      - GNU privacy guard - a free PGP replacement
 gnupg-agent - GNU privacy guard - cryptographic agent
 gnupg-l10n - GNU privacy guard - localization files
 gnupg2     - GNU privacy guard - a free PGP replacement (dummy transitional pa
 gpgsm      - GNU privacy guard - S/MIME version
 gpgv       - GNU privacy guard - signature verification tool
 gpgv-static - minimal signature verification tool (static build)
 gpgv-udeb  - minimal signature verification tool (udeb)
 gpgv-win32 - GNU privacy guard - signature verification tool (win32 build)
 gpgv2      - GNU privacy guard - signature verification tool (dummy transition
 scdaemon   - GNU privacy guard - smart card support
Closes: 648331 734889 852702 854005 854595 854616
Changes:
 gnupg2 (2.1.18-5) unstable; urgency=medium
 .
   [ Daniel Kahn Gillmor ]
   * Xsession.d/90gpg-agent: use simpler and more direct gpgconf
     invocations for socket names.
 .
   [ NIIBE Yutaka ]
   * scdaemon.udev: Add Yubikey and Nitrokey (Closes: #648331, 734889).
   * scdaemon fix for PC/SC (Closes: #852702, #854005, #854595, #854616).
Checksums-Sha1:
 7107ae53a9a7b92c96abd2189b34a0d9cd1fba99 3148 gnupg2_2.1.18-5.dsc
 b31b7f97466e99c49c4eb9320b6df12d32d87e78 67321 gnupg2_2.1.18-5.debian.tar.bz2
 a1c521fc8bf43272c59490065eef86cecf06821d 9975 gnupg2_2.1.18-5_source.buildinfo
Checksums-Sha256:
 8eb4d1d8bb97ac770e8f50e558046981fd6f1fea169ae5e74ac959a6d033a35d 3148 gnupg2_2.1.18-5.dsc
 e6dbc03c9a163baff078a47b0f7c023d8b830f80bf6ae486e6a580fbdb71d9c2 67321 gnupg2_2.1.18-5.debian.tar.bz2
 e24155aeaccd93a834ace33df252d57538679afff471235bb770af4140365ec8 9975 gnupg2_2.1.18-5_source.buildinfo
Files:
 cffe62364ca47384f8347317a5d1a673 3148 utils optional gnupg2_2.1.18-5.dsc
 950b349fb8ed2ee14a00155da3ae2650 67321 utils optional gnupg2_2.1.18-5.debian.tar.bz2
 f39a698baf6d532deab22cb867f3a4b3 9975 utils optional gnupg2_2.1.18-5_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJKBAEBCgA0FiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlihyfYWHGRrZ0BmaWZ0
aGhvcnNlbWFuLm5ldAAKCRAUmK3GwZIyN9UvD/0aFI/Jphk4kTyJC/bx5G7vcgpu
pPCrtlb5/FDvko1XJUMohcS8dFuMf7PPHpQZH31kjqawbQMSzVYhXy9wZL6r+hrg
xz68kJ1CgCTFO/HB+h1dTLASt4OuVGfKGpkuueXenR3kCY7Ghx8H6YOlhYRMtVT6
yWhdpGKHIvR82sCLN61iqMut3NTh47MB1QUmWd1zQPNoGPWLBK2dt7hNvqQWvFZ4
XXsGkjk6LQrZegX4JIrAEjsqIjXQlKJhOWnCA4+86EIVbjnUaYjZKX7q2dHOG21Y
DxT6rn4qx9PCMTR5krJPht4R1hbc6C0aZT4y3I6Cp53FS3uZGD84YxGYND9v5WSb
auu5FGwE0xN+RAbHOVTxh0lIuySJJTkIdX78kqsnuaSaNkXCfgiNo3xacs9uY+9d
TYKg17ouRsbnETkVqpDngTaaaY9pK6ajk/u3uyA3znEWp870ww/7gvrMjCl1gkfP
hinmFseLTKOvHQFlDAZb6HTj/V7SXqSr25hMpSoWNXC8ylypfh90fnDD+YNpFXMm
VND3eZTNtW/EEQTxiWVbDrWXFoIrFTioRHLlbH4rC3dkJ0RjxeMiKcKPzrap/5ht
6vu/nqkBgltt/8UPIctb+6Qe5czMFDJj8T+B/m3+sarCzjd4njHcn0Og4H4flvqY
M07IRiEkzX00kH824A==
=fpGR
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.