Thanks, this version of scdaemon executes.
Mar 9 2018
Mar 8 2018
Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).
Mar 6 2018
@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.
If possible, please try with this (patched version of scdaemon):
I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:
The reference is: https://stackoverflow.com/questions/11294638/how-to-use-scardgetstatuschange-correctly-on-windows-8
It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.
Mar 5 2018
@werner there had to be some mix up, as the log snippet is not mine.
This seems to be the relevant part of the log:
2017-11-18 07:45:15 scdaemon DBG: ccid-driver: CCID: card inactive/removed 2017-11-18 07:45:15 scdaemon ccid open error: skip 2017-11-18 07:45:15 scdaemon pcsc_establish_context failed: no service (0x8010001d) 2017-11-18 07:45:15 scdaemon DBG: ccid-driver: CCID: interrupt callback 0 2017-11-18 07:45:15 scdaemon DBG: ccid-driver: CCID: card removed
Feb 6 2018
Feb 5 2018
Jan 15 2018
I have exactly the same problem on my Windows 10 machine. I am using bitdefender as virus scanner, but it doesn't work no matter if it is active or not. Windows is fully updated and I am using gpg4win 3.0.3.
Jan 10 2018
This is not with 2.0 but with 2.2.3 / current master.
gnupg 2.0 reached EOL - there won't be any fixes.
The install location does not have anything to do with that. I just always have my development installations directly under C: so that I can modify them without admin rights.
well I run "it" on Power Shell ( Debuggable Package Manager ) and I got ..
Jan 9 2018
Do you mean that GnuPG installed to c:/gnupg/bin/ crashed if that mentioned --homedir is given but it does work if it is installed at the standard place? Please run "gpgconf --version" in both ways.
my <output> was the following...
Jan 8 2018
Dec 11 2017
I'd really like to understand what is going on. Thus keeping the report open.
Dec 8 2017
There is now also Gpg4win-3.0.2 with that gnupg version available.
I've been running gnupg-w32-2.2.3_20171207.exe for about as long as it's been available and no hanging whatsoever. Thanks a lot!
Dec 7 2017
All commited. I created a new installer gnupg-w32-2.2.3_20171207.exe which comes with the new libassuan 2.5.1 and the two required patches for gnupg.
Dec 6 2017
I experience this same behavior, standard shell. Both with admin, windows live based account and local, non-admin account.
Thanks for testing.
I created another patch which can be applied independently: D457: Avoid crash using nPth
For better reproducibility of hang, this is more better:
It's a patch to libassuan. The patch to gpg-agent is not the exact one. libassuan patch is the exact one.
I'm doing the test. I'm currently waiting on a hang with the test change applied.
If you can get the developers to make a try-build that is built securely then I'd guess most of us would be happy to try it. Not all of us have a build system for gpg.
To reproduce this problem of nonce write->read race on Windows, and forgotten wrapping of read/write, please apply this patch for testing:
And then, please confirm that rG1524ba9656f0: agent: Set assuan system hooks before call of assuan_sock_init. can fix this, even with the patch for testing.
Dec 5 2017
Alright, I need to weight in with something that may possibly be influencing the failure of the December-01-2017 build to operate correctly over here; since this issue is related to sockets, and I have set up a rather unusual security apparatus on my system ("unusual" as far as computers regularly running GPG are concerned, and that only to my personal experience, meaning no reliable statistics or anything), I think it's worth mentioning that my firewall (Sygate Personal Firewall Pro) is configured to be very restrictive and that virtually anything that utilizes tcp or udp is being routed through socks5 via ProxyCap, and that neither application is currently allowing GPG to have access to any address but localhost (there's a reason for this and has got nothing to do with GPG itself, but that's part of a different discussion).
Dec 2 2017
Ok here's an update.
Superb! Testing gnupg-2.2.3_171201.exe as I type, and it's already working past the time it would normally cease to respond :)
Dec 1 2017
A new installer with an updated libassuan is now available. To download gnupg-2.2.3_171201.exe please go to https://gnupg.org/download/ . If you had the disable-check-own-socket in your gpg-agent.conf, please remove it so that we can really see whether that version fixes the problem.
The error is fixed with "disable-check-own-socket"
If someone is interested for next times, the log-file "gpg-agent.log" is on the path "C:\Users\<my user>\AppData\Local\VirtualStore\Program Files (x86)\Mozilla Thunderbird\".
Adding Windows again because on Unix it is unlikley that our close will block. A documented blocking behavior is only defined for STREAMS
Thanks everyone. I think that the problem is identified and fixed in libassuan.
Nov 30 2017
Update: It was my mistake (typical beginners failure): I had to create gpg-agent.conf instead of usig gpg.conf.
Adding disable-check-own-socket resulted in the right behavior, till now:
After some time-out, GpgOL asks for password again and decrypts the content as expected.
Suppose a client which connects stopped task of server on Windows. In this situation, if the client blocks on closesocket, that is, some user space work is needed for server side for closing socket of client side, this bug can be explained.
If disable-check-own-socket can stop hanging, D454: assuan_close with nPth could be related.
Nov 29 2017
I have created the file "gpg-agent.conf" in the path "C:\Users\<my user>\AppData\Roaming\gnupg\" with the following content:
It's working for me now with that config file as well so far. I'll keep watching too.
I added "disable-check-own-socket" to gpg-agent.conf .
Since 8 hours no "hanging".
I will watch it furthermore...
Could confirm a similar behavior with Windows 7 and Outlook 2010 using GPG4Win 3.0.1.
Time frame for loosing the decryption ability is about one hour or more.
Setting disable-check-own-socket in gpg.conf (didn't find gpg-agent.conf) resulted in "no data" error on all
Can someone please adddisable-check-own-socket
to gpg-agent.conf to test whether this is the cause for the problem. ( note that I asked for this also in T3401)
Sorry for the delay, been a busy busy couple of weeks..
Nov 28 2017
Setting this to resolved until we get reports to the contrary.
Can someone please add
I introduce GnuPG to my friend, yesterday. I saw this problem. It's on Windows 7, gpg4win 3.0.1 and enigmail.
Looking through this report, Windows 7 is common factor.
Nov 21 2017
With the Release of Gpg4win 3.0.1 this error doesn't appear anymore for me while testing.
Nov 20 2017
Not yet located or identified the bug, but some information.
Nov 14 2017
Multiple bugs fixed here:
Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.
Nov 13 2017
Thanks for the report. This is indeed badly broken. I'll work on this now.
I can reproduce and also have a reproducable crash when trying to encrypt a special folder. This must be a recent regression because I tested this some months ago and it worked fine.
Indeed this was a todo that was overlooked.
This might be a reason that we got multiple reports for Kleopatra since 3.0 was released that it hangs on keylisting: https://bugs.kde.org/show_bug.cgi?id=381910
Jochen could you please test this on one of our test VM's again and resolve this then?
Indeed bug in Kleo, it was always 0 in kleo. (likely created during Qt5 port) fixed with: https://commits.kde.org/kleopatra/0d53416cfbe6d8fa087887c428cdfffb13514a7d
Nov 10 2017
Duplicated problem. Solution for the installer is described in: T3434
Nov 9 2017
Both my coworker and I have the same issue. We just started using gpg for git commit signing. Works the first time. Then sometime later, no window pops up and will hang git indefinitely because it's waiting on the agent. Kill the agent and gpg process let git error out. try again, gpg-agent window prompting for password shows up and works.
Nov 8 2017
The thing is that I don't see this bug with verbose logging enabled. So we need to do more code starring or instrument the code
Is there a more detailed logging that i can switch on? Perhaps i can help you to get diagnostic files. Nearly every day i notice this bug. In the log (with "verbose" in gpg-agent.conf) are the same entries i already posted.
Nov 7 2017
So maybe there is also a display problem, as I saw 0:00 in Kleo. I have to recheck.
The default for the timeout are 100 seconds. I will chnage that to 15 seconds which is the same what we use for keyservers.
Nov 6 2017
Also failed to replicate on Windows-7 using a dedicated laptop.
Nov 3 2017
I tested for several days with logging enabled but was not able to replicate it again. Then I tried again w/o logging and couldn't replicate it either.
Oct 28 2017
I have tried this on Windows 10 (1511,1703,1709&RS4TP)
Gpg4win Version 3.0.0
I was using Windows 7 Professional.
The last version that worked was gpg4win 2.3.4 (I didn't try any beta or rc), and encryption/decryption works fine for single files.
Oct 27 2017
Oct 26 2017
Oct 24 2017
I am closing this bug report, as I can't get feedback to fix something.
Oct 22 2017
Can you please try again with the standard shell (and not the power shell)?
Oct 20 2017
gniibe: Can you check the status?
I can replicate this now. Unfortunately without logging enabled.
Oct 19 2017
Here is a part of the log inline:
Additional report in https://wald.intevation.org/forum/message.php?msg_id=5308
Oct 16 2017
I added a Workaround in the Wiki: https://wiki.gnupg.org/Gpg4win/releases/3.0/notes