Please keep also in mind that the OpenPGP card specification has always and is still developed along with GnuPG . Thus if there are any uncertainties in the specification GnuPG's way of handling thing is the way to go. If there is a way to chnage things without risking any breakage we can of course fix that. In all other cases we need to continue wit the current way. For larger changes in the spec we can of course cleanup stuff - Achim is currently reworking on a revision.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 28 2024
Please keep in mind, that it is not only about GnuPG and the OpenPGP card, but also between GnuPG and other PGP applications. I'm not really sure what the recent commit is doing, if it only affect the reading or also the writing of the data. But IMHO GnuPG should stick to the standard also if writing the KDF DO data because eventually, it will be used for authentication with the card.
Mar 27 2024
Given the situation where GnuPG works well with existing OpenPGP card implementations, what we should do here is, perhaps:
There are multiple problems described in your report. Let us handle one by one.
Mar 26 2024
Mar 13 2024
But only if you can figure out in a transaction or locked sytate whether the card needs a verify. Otherwise we have a race between changing the PIN and verifying a PIN.
This rejection could be relaxed.
Mar 7 2024
Mar 6 2024
See also rG40b85d8e8cecadf35e51e84b30de4fac820d714b for gnupg 2.4.
Mar 4 2024
Mar 1 2024
It looks like hardware problem or card reader problem.
Please test with debug-ccid-driver line in scdaemon.conf to see lower-lever (driver debug) message.
Feb 21 2024
The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.
Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022
Feb 19 2024
Feb 15 2024
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 25 2024
Also fixed in the fortgcoming 2.2.43
Jan 24 2024
Fixed in 2.4.4 and 2.2.43 - see above for affected versions.
Works for the two sample RSA cards. Ticket may eventually be re-opened if we run into problems with ECC cards.
We need to fix 2.2.42 too. This because we backported the responsible patch.
Jan 22 2024
Jan 19 2024
Jan 18 2024
We tested with Kleopatra:
- Only gpg4win 4.2 is affected (the current version) but 4.1 is not affected.
- No vsd version is affected.
FWIW, I am already working on this.
Currently, there is no support for gpg-agent to keep private key not on disk, but only on memory of gpg-agent. Given the situation,
I think that it is good to:
Jan 17 2024
Jan 15 2024
Jan 12 2024
Jan 11 2024
The extra option --debug-allow-pin-logging was implemented with commit rGe43bd2a7a78.
Jan 5 2024
Jan 4 2024
Dec 27 2023
It would be good to apply this to 2.2, so adding "backport" tag.
Dec 26 2023
GnuPG 2.2 and 2.4 now have --pcsc-shared option for a user who can control his action in detail.
So, closing this bug report.
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.
Dec 12 2023
Nov 27 2023
It's true that for KEYTOCARD command, there is optional argument for ECDH.
My point is that for PKDECRYPT command, it will be needed to add mechanism for getting such a parameter (when we use KEM API in gpg-agent).
We already have the ECDH parameters for OpenPGP in the gpg-agent API. The question is how large the data for PQC will be - likely we need to use an inquire already for this reason.
Considering the design of gpg-agent which focuses on private key operations and data, it would be better to enhance the gpg-agent protocol to inquire public key data of any format defined by the client (including ECDH KDF parameters of OpenPGP). I mean, instead of storing data in the key file (originally designed for private key + some additional data), we will enhance the protocol.
Nov 23 2023
Nov 8 2023
Pushed the changes for ...sc_op_failure routines to master/2.4.
We would need to revise tools/card-call-scd.c:status_sc_op_failure and g10/card-util.c:write_sc_op_status to catch GPG_ERR_PIN_BLOCKED and GOG_ERR_NO_RESET_CODE.
I found two places in scdaemon which return GPG_ERR_BAD_PIN. GPG_ERR_PIN_BLOCKED is relevant here.
diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 66ec9f4a9..77d428786 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2859,7 +2859,7 @@ build_enter_admin_pin_prompt (app_t app, char **r_prompt, int *r_remaining) if (!remaining) { log_info (_("card is permanently locked!\n")); - return gpg_error (GPG_ERR_BAD_PIN); + return gpg_error (GPG_ERR_PIN_BLOCKED); }
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:
Nov 3 2023
The second retry counter is used by current cards for the Reset Code error counter. It is zero if no reset code has been set. It was used by card specs 1.x for the CHV2 only available there.
This may be related to the output PIN retry counter : 3 0 3, i.e. the PUK counter is 0. No idea what this means.
The same is true for trying to unblock the card with the PUK. Again I have to enter 3 PINs in 3 windows before being informed that the entry in the first window was wrong. Additionally, the text in window 1 is borked
If you try "Change PIN" next, you will be asked for the PIN and 2x for the New PIN in altogether 3 pinentry windows before being informed that the PIN is blocked.
After the 3rd entry of the wrong PIN, this is exactly the same.
Here I would wish for not only the popup "wrong PIN" but additionally this popup should declare "PIN blocked".
This is inconsistent, as usually a separate window would pop up for pinentry errors.
Nov 2 2023
as this really bugs me, I raise the prio.
And add the Kleo tag, as Werner said it might be that Kleopatra is responsible.
Oct 31 2023
With VS-Desktop-3.1.90.258-Beta I ran again into the last issue with "Wrong PIN". I had not realized that I had entered the PIN wrong before (as you have to enter the PIN several times anyway when generating a new key on a card and you do not get an error message on wrong PIN but instead only a new pinentry window...).
Oct 28 2023
Please excuse my question but this issue has been WIP for 8 months. I think it was forgotten a bit. Especially since we are not shipping Okular for general signing of PDF documents this issue might help as a stopgap for Smartcards which we do not yet support natively and reduce the pressure a bit to add more PKCS#15 smartcards which can currently be used with Adobe and Mozilla NSS through their proprietary PKCS#11 modules. So I would like to raise the priority for this a bit. But I don't think high is appropriate. That would be for werner to decide.
Oct 16 2023
Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.
Oct 6 2023
❯ /opt/local/bin/gpg-error 100696144 # installed with MacPorts 100696144 = (6, 32848) = (GPG_ERR_SOURCE_SCD, GPG_ERR_ENODEV) = (SCD, Operation not supported by device)
I am wondering a bit about the gpg: DBG: chan_3 <- ERR 100696144 Operation not supported by device <SCD> which is not the string I expected for this error:
Sep 28 2023
Changing debug options unfortunately didn't change much.
Sep 26 2023
Eva and me tested this using our 2.2.42 release candidate on Linux and
on Windows and were not able to replicate your problem.
Eva can you please try to reproduce this? I can't really imagine that this is true since we have soooo many users with yubikeys and do a lot of internal testing on them. To be fair please try with your standard devuan GnuPG and not just with an up to date version.
Sep 25 2023
Aug 29 2023
Aug 23 2023
Aug 1 2023
Dear Werner, have you had any toughts about this ?
Jul 4 2023
May 26 2023
May 25 2023
May 8 2023
If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.
The root cause might be that the "DEVINFO --watch" command causes ...