Fri, Jan 8
Thu, Jan 7
I'm also getting this same error with GPG4Win 3.1.14.
Wed, Jan 6
I wrote https://github.com/rupor-github/win-gpg-agent to simplify usage on Windows until this issue is resolved - it handles various edge cases on Windows.
Tue, Jan 5
Dec 23 2020
Already have set another, thanks gnibe! See ya!
Please change your passphrase for your card, BTW.
Good. The error recovery worked well.
Dec 22 2020
$ gpg --card-status $ gpgconf --kill scdaemon $ git fetch << (Used my PIN, I have reverted to my previous code other day, is not anymore 123456)
Dec 21 2020
Thank you for your testing.
May I ask more test, please?
Dec 20 2020
Hi, I have applied both patch and appears Yubikey is now working correct. I have uploaded the log here.
Dec 16 2020
Nice, I gonna apply the patch and see if resolves for me!
Dec 10 2020
With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2) 2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02 2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed 2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0 2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0 2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0
Dec 9 2020
I checked the development log for the addition of:
libusb_clear_halt (handle->idev, handle->ep_intr);
I have another yubikey neo but its clean. Can it help it?
Dec 8 2020
Changing modes will I lose/change my OTP and FIDO codes?
Following device (a bit older than yours, I guess) works well:
DBG: ccid-driver: idVendor: 1050 idProduct: 0112 bcdDevice: 0334
When I configure it to OTP+FIDO+CCID, it also works for me, it is:
DBG: ccid-driver: idVendor: 1050 idProduct: 0116 bcdDevice: 0334
Thanks a lot.
Let me explain the situation.
Dec 7 2020
Hi, I changed the PIN, killed the gpg-agent and scdaemon, edited the scdaemon.conf to include your instruction, after, I run the following commands:
Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.
Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?
Dec 6 2020
There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.
Nov 23 2020
Removing 2.2 tag because it has been fixed in one of the last releases.
Oct 1 2020
@werner can you confirm if the environment I provided will work with OpenSSH support fully implemented?
Sep 26 2020
That code in gnupg has not been touched in a very long time so this may be caused by some side effect.
Sep 11 2020
Fixed in Gnuk 1.2.16, although it still has a limitation by the I/O buffer size.
Sep 4 2020
So, if there's no support for native OpenSSH yet, I'll wait for it. After it's supported, I should be able to get the scenery I described working, right?
Unfortunately you can't pass extra arguments.
Thanks for your information. No debug output any more, as I already figured out things.
Sep 3 2020
In case of Ed25519 certificate signed by Ed25519 key with only few names and flags it seems to be just below 500 bytes. This could of course grow if names are added or larger public key is being signed.
@bvieira You need to set pinentry-mode=loopback for gpg program used in git.
Well, from the viewpoint of card specification, "a message M of arbitrary size" for Ed25519/Ed448 in RFC8032 is not good, because card has a limit for buffer size and the protocol in the OpenPGP card specification requires the steps of (1) the message M is buffered and then (2) the compute the signature.
Sep 2 2020
I'm actually trying to do the following:
In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.
I just confirmed that Gnuk has a limitation for the input length is less than or equals to 256.
So, this is the issue of Gnuk, not GnuPG (or at least, Gnuk has the problem).
Please show us concrete example of debug output by scdaemon, when you run ssh-keygen.
You can have a setup in .gnupg/scdaemon.conf like:
Sep 1 2020
I've meant scdaemon rather than OpenSC. I'll correct the descritpion.