That is an old bug report with a couple of fixes introduced over the years. As of now we sometimes see hangs on Windows on our test VMs. The common cause here seems to be USB card reader issues. Let's close this bug and wait for another bug report with current software versions.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 30 2024
Since 2.2.20 we had these items in the NEWS
Jan 29 2024
Jan 26 2024
We need to test the PIN, PUK and reset code stuff in 2.2
Is in 2.4.4 and will go into 2.2.43
Oh, well it does happen only with --status-fd=2 because of a c+p error by me. For status-fd > 2, as used by GPGME, there is no problem, because this is handled by an exception list.
Jan 25 2024
Are you seriously using version 2.0 which had its EOL of 6 years ago? Libgcrypt 1.5 EOF was even a year earlier. Sorry, I won't look into that.
Also fixed in the fortgcoming 2.2.43
Jan 24 2024
Just a reminder, this is important for 384 bit keys (see T6379).
The state of the brain is:
These gpgsk files are standard private-keys-v1 files with an additional Backup-info line showing for example the keygrip.
There are no certificates in the file, thus we can either use gpg or gpgsm as driver.
No test environment in our QA dept.
Fixed in 2.4.4. Feel free to re-open if you still see problems.
No regression, assuming things work.
Hard to test without instrumenting the code.
Tested during development.
Tested for 2.4
@alexk and me tested this. The core functionality works.
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.
Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24
Closing because we believe things are fixed and our test suite confirms that. Feel free to -reopen in case your own file does not import with 2.4.4.
The test file is now part of our test suite and passes.