Page MenuHome GnuPG

Should not be required to manually `killagent` on card removal
Closed, ResolvedPublic

Description

Recently I have been setting up gnupg for a decently sized userbase. I notice
that the hack documented here https://www.sidorenko.io/blog/2014/11/04/yubikey-
slash-openpgp-smartcards-for-newbies/ (part relating to NOCARD event in scd-
event) is still required.

If there is an actual fix for this, I'd love to know. Otherwise, this seems
like a fairly common issue which should be better understood and fixed. Nearly
every guide I've seen about setting up gnupg has included something to this
effect. Mostly, people tell you to manually kill gpg-agent or related processes
when things don't appear to be working properly ... quite a sad state of
affairs.

Event Timeline

By the way, I've noticed that communication with the card will only be broken
upon reinsertion if some software has attempted to access the card while it is
detached.
In other words:
access card -> remove -> insert -> access card
is fine.
access card -> remove -> access card -> insert -> access card
will cause all accesses to fail after insertion until gpg-agent is killed (and
restarted obviously).

Please tell us which version of GnUPG ayou are using and on what OS.

gpg --version

gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
libgcrypt 1.6.6
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:/Users/<username>/AppData/Roaming/gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Yes...seems old! But this is what latest gpg4win packages. :(
It is also the latest stable gpg release...so normal, I guess.

I've installed gpg on various recent Windows 10 builds (~10 machines/builds)
and noticed the behavior on all of them. For example builds 14939, 14986, and some
others.

FYI: It is fixed in 2.1.
Backporting the change to 2.0 will be a bit large, and I hesitate to do that.

A backport to 2.0 does not make anymore sense given EOF in 2 months.

I close this bug as resolved (in 2.1).