Rhat's for the client, right. I never used it. We used to run a Windows 8 instance in a VM to run tests via ssh on it. That worked most not really stable. For obvious reasons I am more interested in the server part ;-)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 10 2018
Thanks. I took these patches and simplified them. Not test tested, though,.
I would argue that the Windows port of OpenSSH is not unstable at this point, especially given that Microsoft is even providing it as an installable feature in the next regular Windows 10 release. The fact that the port is now using actual OpenSSH version numbers instead of their own 0.x versions lends credence to this as well.
Thanks for the fix! however, the fix only addresses the two flags we currently know about. I've pushed a branch T3880-fix that tries to implement the If the agent does not support the requested flags […] It must reply with a SSH_AGENT_FAILURE message part of the spec.
Apr 9 2018
It is in 2.2.6
Thanks for the pointer. But as long as the Windows ssh server is that instable I see no urgent need to add this to GnuPG.
Apr 7 2018
Apr 6 2018
Apr 5 2018
Mar 28 2018
Mar 27 2018
Mar 23 2018
Mar 13 2018
I've contacted Yubico to review this ticket.
Hi, that works as advertised. If this is the best solution yubikey permits us I am ok with it.
I put an entry: https://wiki.gnupg.org/SmartCard#Known_problem_of_Yubikey
After resume, because resume is not detected, some user interaction is required to cause an error.
gpg --card-status (which will only show partial information) is enough. Or, ssh failure. After failure, scdaemon reconnects the token.
Then, you can use it again without plug-off/plug-in.
Thanks a lot for pointers and suggestion.
Well, the problem of Yubikey itself cannot be solved by others, we can put some workaround for the error recovery.
So, this is another try of mine to improve error recovery.
Mar 12 2018
- There was same problem in yubico-piv-tool and it was solved by detecting error state (0x80100068) and reconnecting to the smart card if necessary [1]
- There is also a thread in OpenSC discussing this issue [2] and relevant PRs [3]
- I also found a project that claims to fix SCARD_W_RESET_CARD by disabling exclusive access to the card before asking for PIN (and then they enable exclusive access again) [4]
Part of the problem is Yubikey side, I suppose. (Because my implementation of Gnuk Token has no problem for suspend/resume if it's in-use.)
Again, thanks a lot for your testing. The log said: The code I added cannot detect the event of suspend/resume.
It seems that there is no way to recover from suspend/resume for Yubikey.
Mar 9 2018
Yeah, this is better, we got apdu_get_status => sw=0x0 status=7 and I can auth with this version as usual. After sleep-wake cycle it would however fail with pcsc_transmit failed: reset card (0x80100068). Logs attached.
Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)
Mar 8 2018
Thanks, this version of scdaemon executes.
Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).
Mar 7 2018
Probably you are right but I don't know Windows internals that much.
I wonder if this also works similar in a multi user system:
Mar 6 2018
Fixed. But you need to wait at least 4 seconds even with a 2 seconds ttl. Will go in 2.2.6 in about 3 weeks. Thanks for reporting.
Well, if you have access to the user's memory you are lost anyway. Should be fixed, though.
@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[8918] DBG: ccid-driver: CCID: card inactive/removed 2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip 2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d) 2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0 2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed
Feb 26 2018
Feb 16 2018
The error of testQuickUID is strange. In the test, it adds a UID and checks number of UIDs (3 + 1 = 4).
It is not reproducible for me (Debian with Qt 5.9.2, NetBSD 7.0.2 with Qt 5.5.1), gnupg 2.2.x from the repo.
Feb 15 2018
(automake should flag non-portable Makefile features - after all it is there to avoid gmake features)
Thank you very much! This is working quite well now.
I believe that all BSD Makefile issues has been fixed (except python-tar-gz distribution thing for maintainer).
Please test again.
I located the problem. It's Makefile portability issue and it is fixed in: rMb5ec21b9baf0: tests: Makefile portability., rMba6e610baa13: tests: More Makefile portability., and rM3224d7f0ea83: tests: Fix previous commit
It was not your final invocation of "make check" (GNU or BSD), but the one before ("make all" by BSD make) which imported keys for tests.
The "export" directive doesn't work on BSD.
Feb 14 2018
/* Print all commands. If a help string is available and that starts with the command name, print the first line of the help string. */
For SETKEY this is not true. To change this we would need to have an "alias" flag to tell libassuan that setkey is an alias of sigkey. Not sure whether this really makes sense.
OK. Then, it may be some bashi-ism in Makefile. I'll investigate with no bash installed.
Feb 13 2018
No, I don't have a smartcard. Perhaps it misdetects one?
For other failures, I guess that you are connecting your card, aren't you?
Last year, I introduced a change for key selection to prefer existing card key. That may affect tests. Well, tests should have configure not to try to access card.
Feb 6 2018
For scdaemon process(es), I created a ticket T3778: NetBSD: scdaemon should be killed when its parent (gpg-agent) is going to shutdown.
Feb 2 2018
I'm confused. I've just now retested, and I get further with BSD make (there is another problem when importing the keys into the test keyring, where it the error is ignored with GNU make but the build fails with BSD make) but that is not what I want to focus on.
Jan 30 2018
Thanks for your additional suggestion. I pushed the change.
Jan 29 2018
For qt: adding /usr/pkg/qt5/bin to the path makes the build succeed. I think you should take a look at the build rules though, since it seems that it wants to execute the header file if "moc" is not found.
For BSD Make issue, please try:
For the latter, I think it requires path to moc, which may be like /usr/pkg/qt5. Please add it to your PATH. Then, retry from configure
Using BSD make on git head of gpgme, I see
Other problems are fixed. Please test. It works for me on NetBSD 7.0.2.
Jan 26 2018
Checked - it builds fine now. Thanks!
I push my change to master.
Please test.
Jan 25 2018
Thanks for testing master.
No, it's not typo, in my opinion.
The line was added as if it's LOCAL_PEERUID, but there is no such a thing in XNU, but there is LOCAL_PEERUUID which is for UUID.
Jan 9 2018
Dec 12 2017
Okay, lets try with a default of 64. Note that for many concurrent ssh sessions you may also need the option --auto-expand-secmem which will come with Libgcrypt 1.8.2 and GnuPG 2.2.4
Please open another report, not reusing similar. I don't think it's same bug.
Please note that GnuPG's ssh is not fast enough (intentionally), its rate is usually ten connections per second.
Dec 11 2017
I'm seeing something quite similar - same setup, osx and it only shows when using ansible. I'm on gnupg 2.2.3, also saw same using "GPG Suite 2017.2".
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
Thanks for testing.
I created another patch which can be applied independently: D457: Avoid crash using nPth
Tested it on Windows, with the sleep test patch in Libassuan it does not hang anymore when it hanged without this change.
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
Yeah, that looks correct. Good catch. The bug exhibits itself when gpg-agent checks its own socket. In this case gpg-agent is both, client and server, and due to our userland multi-threading we get blocked. The suspend/resume things makes the deadlock more likely. Note that we have the same problem on Unix.
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
encrypted e-mails.
In T3378#106503, @raysatiro wrote:I assume it goes in %APPDATA%\gnupg\gpg-agent.conf.
In T3378#106440, @werner wrote:Can someone please add
disable-check-own-socketto gpg-agent.conf to test whether this is the cause for the problem. ( note that I asked for this also in T3401)
Nov 28 2017
Can someone please add