I also experienced hang on shutdown with GPG 2.4.1 and bisecting reveals that the first bad commit is rG2ccbcfec121f.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 7 2023
Apr 28 2023
Closing. A small change in Kleopatra (T6472) should help to avoid using this hack in common cases.
Apr 27 2023
The workaround works.
Apr 21 2023
Apr 20 2023
Not easy to fix because gpg --card-edit/-status has some support form other cards. Eventually these commands will be replaced by gpg-card. In the meantime we can use this hack:
Apr 19 2023
The generate keys etc. actions in the keys part of the view are debatable. At least for VSD I think they should not be shown or greyed out for not VS-NfD compliant cards -> see T6786
(I think there were even algorithms offered for generation on card which would result in an error, but I won't investigate further at the moment.)
Apr 14 2023
Apr 13 2023
isn't T3456 the same issue?
Apr 5 2023
Mar 28 2023
Mar 15 2023
works. tested with VSD 3.1.26 (gpg 2.2.41) and keyserver entry in dirmngr.conf only.
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 6 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.
Feb 10 2023
I try experiment using Python PKCS#11 (https://python-pkcs11.readthedocs.io/en/latest/index.html)
- with SoftHSM https://github.com/opendnssec/SoftHSMv2
- with Scute
I concluded that (at first, for the initial try) it's not good to start this under scdaemon, because of two different abstractions for accessing the device (the way of scdaemon and the way of PKCS#11).
It's good to start with something like tpm2d. The goal would be integration into scdaemon or tpm2d.
Feb 1 2023
Jan 26 2023
Jan 19 2023
Dec 12 2022
Dec 9 2022
I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.
Dec 5 2022
Nov 28 2022
Nov 17 2022
In T6282#165263, @werner wrote:It turned out that the reason for the problem is the use of the --ignore-cert-with-oid option in gpgsm.conf.
It turned out that the reason for the problem is the use of the --ignore-cert-with-oid option in gpgsm.conf.
We need to do this also for CHANGE REFERENCE DATA - however, there should be an extra option so that we can debug this despite of the redacting.
Nov 14 2022
Oct 28 2022
Will be released with 2.3.9
Oct 20 2022
Oct 11 2022
is there any news for gnupgp 4.0.4 release with gnupg 2.3.8?
Oct 10 2022
Oct 9 2022
In T5790#163980, @manonfgoo wrote:
Oct 8 2022
In T5790#163886, @werner wrote:[Merging didn't work]
Can you test the Patch, does it work for you ?
Oct 7 2022
Here is the patch as file:
The patch applies with -p1 to the master brach, alternatively I could push a commit, but my user does not seam to be allowed to do so:
[Merging didn't work]
Oct 6 2022
Attached you find a patch to this issue. This Patch sets the "keypair" attribute to the keys 0x82 to 0x95 unconditionaly.
Oct 1 2022
In T6218#163787, @gouttegd wrote:Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?
Yes. Scute relies on those to interact with the token.
Sep 30 2022
Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?
Sep 28 2022
That sounds quite cool.
Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.
I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.
Sep 27 2022
Which version of Scute are you using?
Using Scute as a drop-in replacement doesn't currently work. Perhaps my config needs more adjustments than just:
module = /usr/lib/x86_64-linux-gnu/scute/scute.so
Sep 26 2022
Yes, I meant to use Scute as pkcsc11 module for pam_pkcs11. Thanks for explaining more verbosely what I meant.
I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)
I'm not sure what you mean with using Scute as PKCS#11 provider instead of pam_pkcs11, as pam_pkcs11 is not a provider but a user of PKCS#11
There is a reason why pcsc-shared is not the default ;-). Please try using Scute (best the t6002 branch until it has been merged) as pkcs#11 provider instead of pam_pkcs11. And you should of course use the stable version of GnuPG and not the LTS (2.2).
Sep 22 2022
Sep 20 2022
Testing gpg-auth : There are two different use cases
- test with xsecurelock for screen lock
- test with pam-autoproto for login / gdm / etc.
Here are pam_authproto.c with Makefile, so that you can compile it with libpam:
Sep 9 2022
Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.