We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.
Tue, Apr 9
Fri, Apr 5
Wed, Apr 3
Wed, Mar 27
Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com
Tue, Mar 26
From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25
fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.
Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.
Feb 10 2019
Patch applied, thanks.
Patch applied, thanks.
Feb 8 2019
Jan 28 2019
fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.
That is a very interesting problem that we did not have on our radar.
Jan 25 2019
Jan 23 2019
Jan 21 2019
I've developed a simple patch that sets the CREATE_BREAKAWAY_FROM_JOB flag when creating a new background process. This flag requires a special permission on the job object, which is tested first. This means that the patch only works if the parent process sets JOB_OBJECT_LIMIT_BREAKAWAY_OK on the job object, otherwise the behavior should be as without the patch.
Oct 15 2018
Just commited. Thanks.
Jun 18 2018
On 06/17/2018 02:10 AM, BenM (Ben McGinnes) wrote:
The two subsequent commits are the one I mentioned above (nested try/except
statements) and followed by a major PEP8 compliance overhaul of core.py.
Thanks for the patch and welcome to the weird and wonderful world of FOSS. :)
Jun 17 2018
Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960
Not to worry, we've all been pretty busy of late.
Jun 8 2018
Apologies for the delay, been working on GSoC stuff.
Here's what I've got as of right now:
Jun 6 2018
Jun 4 2018
Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.
Jun 3 2018
That makes sense. If you don't have any other patches floating around for this, would you mind if I took a crack at rewriting export?
Jun 2 2018
Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.
Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).
May 29 2018
Jan 29 2018
Ah, yes. Will do. Thank you for reminder.
Thank you. I think you can update the comment below the implementation now ("/* FIXME: Implement this when we have the specification for it. */) and the #error line.
Jan 7 2018
Nov 15 2017
I prefer plain git patches. Thanks.
Nov 14 2017
I created a Differential request for this change; not sure which you prefer.
Oct 26 2017
Oct 24 2017
I am closing this bug report, as I can't get feedback to fix something.
Oct 20 2017
gniibe: Can you check the status?
Aug 31 2017
Thanks. That reminds me again that a GPA release is due.
Aug 29 2017
Do you have the specs for getenv_r? I can't find such a thing on FreeBSD or Debian
Jul 5 2017
Thanks. Will go into the next release.
Jul 2 2017
Jun 28 2017
Jun 26 2017
Jun 22 2017
May 23 2017
Mar 30 2017
Oct 17 2016
I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.
Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.
Mar 18 2016
Applied to master will go into 1.7.
Mar 16 2016
I believe I have also seen this issue (or something very similar) on my Windows
7 64bit machine. I am running gpg 2.1.11. I hope this isn't redundant, but it
seems that I need to restart scdaemon anytime I unplug/replug my yubikey or
suspend/resume my computer.
Sometimes it doesn't recover even after restarting scdaemon. In those cases, I
am able to fix it by stopping scdaemon, removing the yubikey, starting scdaemon,
and finally reinserting the yubikey.
Dec 22 2015
Thank you again.
It is likely that the token itself doesn't work well after wakeup from sleep
mode. In this case, all that we can do is re-inserting the token manually.
I'm not sure how PC/SC service handles USB reset after wakeup.
Sorry to say, but mapping the error to "no reader" doesn't help. The first
reset event doesn't get handled. Later it trys to remove the reader but it's
not getting correctly resetted/reinserted again.
I've attached the debug log again
Thank you for further testing.
I think that current code doesn't handle the case when card goes inactive/reset
while reader keeps working. Current code only goes to the reset sequence for a
card again when it detects reader failure. So, although the concept is
different, I think mapping PSCS_W_CARD_RESET to SW_HOST_NO_READER (for now) will
work. Given the situation we don't yet support multiple cards, this workaround
would be OK for a while.
Nope. Neither mapping the "reset card" event to SW_HOST_CARD_INACTIVE or
SW_HOST_NO_CARD helps. It seems that somewhere in the code the return code
SW error codes are not being handled correctly and the card doesn't get
I've attached a small log where you can see that pcsc returns the error
reason "reset card" which then gets remapped to "Card reset required" (was
general error before). I also can see that the error is getting mapped to
GPG_ERR_CARD_RESET (because of the error message "Card reset required")
leaving the daemon around with no working card and reporting general errors
Additional Info: This bug only happens when you put your computer/laptop
into sleep mode while the smartcard/reader (yubikey) is plugged in. If I
remove the reader before putting it to sleep and attaching it after getting
out of the sleep mode, the scdaemon works fine.
Dec 21 2015
Maybe it's more appropriate to map the PSCS_W_CARD_RESET event to the
SW_HOST_CARD_INACTIVE error code which later gets mapped to GPG_ERR_CARD_RESET
I've attached the patch file. It would make sense to backport this mapping as
well. Right now it's not yet tested.
I found another problem with the smartcard service under windows. Putting
the system into sleep mode and waking it up again creates an 0x80100068
error code (aka PCSC_W_RESET_CARD).
I'll test if it helps to map the RESET_CARD event to the same REMOVE_CARD
event to get the card reactivated after sleep mode.
2015-12-21 22:16:57 scdaemon DBG: send apdu: c=00 i=CA p1=00 p2=C4
lc=-1 le=256 em=0
2015-12-21 22:16:57 scdaemon DBG: PCSC_data: 00 CA 00 C4 00
2015-12-21 22:16:57 scdaemon pcsc_transmit failed: reset card
2015-12-21 22:16:57 scdaemon apdu_send_simple(0) failed: general
Dec 11 2015
Thank you for your testing.
Your change is pushed with my comment:
I'll backport this to GnuPG 2.0.
Dec 10 2015
Here's the logfile with all the errors (guru debug level) vanilla 2.1.10
After some time spending fighting with the build tools of gnupg (cross compile
for windows under debian) I managed to build the installer with my patched
Most important: The most common error thrown is the 0x8010001e
(E_SERVICE_STOPPED) This is the important one. The other error 0x8010001d
(E_NO_SERVICE) is only thrown in the transition from ok to stopped. So only
This was my process:
git clone git://git.gnupg.org/gnupg.git
git checkout tags/gnupg-2.1.10
cat ../0001-scd-Fix-removal-of-unplugged-usb-readers.patch | patch -p1
sed -i -e 's/^SELFCHECK=1/SELFCHECK=0/' build-aux/speedo.mk
make -f build-aux/speedo.mk w32-installer
I've created new logfiles (vanilla 2.1.10 und patched 2.1.10) to show the
difference and confirm that it'S actually working now :-)
I'm okay with signing off the commit. I can test this for Windows 8.1 or 10,
my only problem is that I'm not able to compile gpg for windows right now. Or
are there instructions somewhere on how to achieve this?
Thank you again.
I think that Windows 8 (and later) changed the PC/SC service. The service is
only available when smartcard is there, and after the removal, it returns
PCSC_E_NO_SERVICE error. This is not expected for current code.
I'm applying your patch with my comment like above. Do you agree to put the
line in the commit log?:
Signed-off-by: Daniel Hoffend <firstname.lastname@example.org>
I don't have Windows 8 machine. So, I leave this issue as testing.
No, I just installed version 2.1.10 (which included your mentioned fix). But the
error still applies.
In my case the smartcard reader never gets closed, cause the error thrown by the
pcsc/scd gets only mapped to a general_error which does not result in
removing/closing the reader interface.
I've the feeling that we've to take a closer look at the errors thrown (at least
those 2 in my patch). Maybe there're even more possible events.
If you like I can upload the debug log of scdaemon 2.1.10 ... (if that helps).
Somehow I don't have any issues when running linux, this bug applies to windows
only atm. Maybe it's just that windows is throwing different errors or events
compared to linux.
Thank you for the bug report with log.
It could be related to the bug which was just fixed:
I'm backporting this to 2.0.x.
Dec 7 2015
After looking at the gnupg 2.0 branch I would say the patch could be applied
to the 2.0 and 2.1 branch to fix the issue in both branches stable/modern
since both version are affected (tested with 2.1.9 and 2.0.29 from gpg2win)
Nov 6 2015
At most, this is a performance bug. However, applygnupgdefaults isn't
performance critical. There is no reason to apply this so I'm dropping it.
Sep 8 2015
Sep 7 2015
To be considered for 1.7
May 6 2015
The patch is a work for problem somewhere in the PC/SC implementaion. I am also
not sure whether a pthread_cancel for a buggy PC/SC library is a good idea.
Terminating the process seems to be a better solution.
If gpgtools wants to apply this pacth, they might of course do so but I don't
want to apply it upstream in particular not to an older version (2.1 is current).
May 4 2015
Apr 8 2015
Done in c238340:
Apr 1 2015
I created (1938) a new issue for the extreme slowness of --list-sigs on a
keybox. 1938 is most likely a bug, while 1710 is merely a quickfix for an
algorithmic issue in --list-sigs. However if with keybox “random access to the
keys is now really fast”, maybe it a proper fix could easily be implemented
instead. See also