Wed, Mar 6
See also rG40b85d8e8cecadf35e51e84b30de4fac820d714b for gnupg 2.4.
Jan 26 2024
We need to test the PIN, PUK and reset code stuff in 2.2
For the particular issue reopened for GnuPG 2.2.41 is fixed in GnuPG 2.2.42.
Please note that we can't fix the cause itself, the hardware problem.
Jan 12 2024
Jan 5 2024
Dec 27 2023
It would be good to apply this to 2.2, so adding "backport" tag.
Dec 22 2023
Thank you for the bug report. Although it's a corner case, it is a discrepancy in the implementation which results unrecoverable situation of the device.
Nov 28 2023
Nov 27 2023
Nov 7 2023
Applied a patch from 2.4/master to 2.2 for SEGV when card gives bogus data. rG600e69b46149: scd:openpgp: Fix a segv for cards supporting unknown curves.
Nov 6 2023
@desultory Thank you for your report.
Please open a new ticket for your problem. If you can, please show the result of https://dev.gnupg.org/T5963#157724
Nov 5 2023
This is still an issue for me:
Apr 21 2023
Mar 14 2023
Closing this one - see T6378
There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check
Mar 13 2023
I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.
Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.
Mar 11 2023
Feb 26 2023
Feb 21 2023
The application probably doesn't support this curve, the changelog only mentions Curve25519 and NIST P-256. Also Kleopatra lists only these two curves when generating a key from the card. Upon further inspection, the 0xFA DO listing the supported algorithms only has RSA 2048, RSA 4096, nistp256, ed255519 and cv25519
This is a Nitrokey 3A with the firmware 1.2.2-alpha.20221130. I'll check with the vendor.
Sure that you specific card/implementation of Nitrokey supports this curve? The card application uses a vendor from the test card range - this it is likely that it is some Javacard implementaion or it is an old gnuk firmware on the nitrokey basic.
Changing the key attributes didn't help unfortunately:
There must be some regression in the code which changes the key attributes. Please try
"gpg --card-edit" admin, key-attr
and switch to nistp384.
I also tried to import the key with the gpg-card writekey command and I got the same error.
Same error message but probably a different cause, in this case the card was factory reset before importing.
Jan 17 2023
I am very sure that this is resolved and we support that in Kleopatra.
Oct 7 2022
Oct 6 2022
Pleaee have a look at https://dev.gnupg.org/T5790, i added a patch.
The other key slots are claimed to be used for expired or archived keys as you rightfully mention. We need to figure out the real world semantic behind this before we can repurpose such keys.
Jul 12 2022
And 2.3.7.
Fixed in 2.2.36.
May 18 2022
Glad to hear. I've also now had time to manually apply the patches and have not seen any issues so far! Thank you! If anything does turn up later down the road I'll let you know.
No, no apologize needed. You did your best for the bug report, and it helped us a lot to identify the issue, and it certainly helped resulting the fixes. Moreover, your report kicked another fix of T5979 (thanks to the valgrind output).
Thank you.
May 17 2022
I apologize, you seem to be right. Even though the package build log shows that all patches were applied, it seems there are some hunks missing in the generated sources.
I've attached my patches, but those are most likely correct. There seems to be an issue with my distribution's package manager. I will investigate this and report back afterwards. Maybe I'll just build it manually.
When compiling the package, I can see that all 4 are applied.
May 16 2022
I think that it means that you only applied the last two patches.
Thanks again for your update.
May 13 2022
Thanks a lot for your cooperation.
I put more fix for error handling of key algorithm attribute.
The change: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.
Thanks a lot for your cooperation.
May 12 2022
Contrary to your expectations, all gpg --card-status fail after yubikey insertion: