gpg-agent has a pinentry caling timeout - doesn't that trigger?
In any case we agreed that Debian takes care of systemd support because that is not an upstream supported configuration.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 21 2018
Jun 8 2018
Jun 6 2018
Thanks. I added all standard names to that list.
May 17 2018
May 16 2018
@werner I was hoping to make a modified gpg-agent build that would let me walk through what's going on after the nonce is sent but it looks like the gpg4win process only takes in a package of pre-built gpg binaries which rules that out. As far as I can figure out, after the nonce is read and accepted, libassuan creates a stream object out of the socket and then finding nothing in the stream terminates the ssh handler. We send the actual client request immediately after the nonce but in a separate call to send() so I now wonder if by not having anything read in at the same time as the nonce gpg-agent or libassuan thinks that it's a 0-length stream.
Apr 27 2018
Apr 21 2018
I just took a look through assuan-socket.c and it appears that we just need to send the nonce and don't need to read anything back. We also found a bug on our side that was preventing the nonce from being sent, which has been fixed. The error message logged above no longer happens.
The nonce is a string of octets thus it needs to be passed verbatim. I would need to study the code in libassun/src/assuan-socket.c to tell more.
Apr 20 2018
@werner After sending the nonce value from the socket file, does anything need to be read back before ssh-agent commands can be sent? Are there any byte ordering requirements for sending the nonce or can they be sent in the same order as they are in the file?
Apr 14 2018
I've been working with one of Microsoft's developers on a temporary tool that should bridge the connection between named pipes and the Unix sockets emulation used by gpg-agent but things appear to trip up with sending the nonce. From the position of the tool, the nonce value is successfully sent (send returns 16), but never seems to be picked up by gpg-agent. Instead both gpg-agent and the bridge sit there until whatever tool is using them (I test using ssh-add -l) is terminated, at which point gpg-agent immediately spits up the message
Apr 11 2018
Workaround is implemented in 2.2.6.
Apr 10 2018
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 ;-)
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.