Another important use-case is to provide a way to migrate to a newer smartcard.

Please continue on T7041. This ticket is going to be closed (as the problem described was fixed already).

Yes I have pcsc-shared in my scdaemon.conf.
I've just tried removing both pcsc-shared and disable-application piv and PIN caching worked as expected.

Are you using PC/SC shared mode? If so, it may be the case of T7041.

Pretty obvious. RENC is an allowed usage for an RSA key and thus set in the mask. I restricted this but allowed to set it anyway when using the "=sr" shortcut (here to set as signing and R-enc). Thanks for reporting.

The reset was due to running gpg-connect-agent reset /bye. I am currently testing something elese will get back as soon as I can turn back to 2.4

There are two locks here; (1) rw_lock for card_top (list of cards) access and (2) individual card lock.
It looks for me that:

• don't know how/what the thread 7208.2 does
• the thread 7208.3: KEYINFO, then PKSIGN (gets read lock for card_top, then, individual card lock)
• the thread 7208.4: SERIALNO --all (and wait for write lock for card_top)

In case if someone finds it through a search:

How to test:

So after taking this down to where it was only patching status.h and mainproc.c to add a write_status_output() I realized the whole issue is down to status-codes.h not being updated automatically if you apply a patch to status.h in a released version.

Having looked at the build log again after applying the patch, I see the first test failing is

Okay, backported to 2.2.

I need to come up with a better strategy here. --refresh-keys is a very useful command and it should do what the user expects. Maybe we can adjust the behaviour iff we detect that there is an LDAP keyserver.

Interesting. So the problem is not actually the Key-Type, but that the default key-type requires a Key-Curve parameter which has no value by default

I was wrong for the semantics of proxy->outtoken. It is zero when run_proxy_connect is called and enabled during the negotiation.

@hlein Thanks a lot for quick testing.

Thank you @gniibe! Applied the rG848546b05ab0: dirmngr: Fix the regression of use of proxy for TLS connection. changes here, and 2.4.4 works here now.

IIUC, the code for keep_alive is for negotiation of proxy. If so, something like this is the fix:

Right. I was wrong assuming the code in 2.2 branch is stable (that is: well tested).

Per https://dev.gnupg.org/rG04cbc3074aa98660b513a80f623a7e9f0702c7c9#83517, it looks like the fix might be incomplete?

Werner wants the import via gpg-agent

Thank you for the report. There was a problem in: rG845d5e61d8e1: dirmngr: Cleanup the http module.
Pushed the fix in: rG04cbc3074aa9: dirmngr: Fix proxy with TLS.

It works in 2.4.4 if you add

So I cherry-picked this onto 2.4.4 and I ended up with a failing build due to failed tests (it built fine without the patch)

We check the actual used signature and the corresponding (sub)key. Whether you trust this key is a different thing and we are not able to check that. Note that the same subkey may be used with different primary keys. The whole point of gpgv is to that you pass a list of trusted keys - actually this makes this new option superfluous but in gpg it makes sense. It was easy to add it to gpgv, though.

Checking if the file already exists doesn't help. In fact, typically the file (containing the shadow key for the card key) will already exist. But one could check if there is already a private key with this keygrip. Then restoring could be refused, so that the worst that can happen is that the shadow key (which can be recovered from the smart card) is overwritten with a corrupt file.

I think the attack ingo talks about would mostly be covered by checking if the file already exists before moving it into the private directory.

Do note there could be subkeys as well.

I recently stumbled upon this as well.

Setting a date on the command line is in UTC, displayed in Kleopatra is the corresponding local date which might therefore be one day of. This is as intended and the same for dates before or after the Y2038 cut off.
-> Works with Gpg4win-4.3.0

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.

Fixed in 2.4.4.

Hidden for Gpg4win-4.3.0-beta571, too

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.

The test file is now part of our test suite and passes.

We meanwhile have a lot of test cases in our test suite and we see no issue. Closing this bug; feel free to re-open if it is not fixed for your case in 2.4.4.

We need to fix 2.2.42 too. This because we backported the responsible patch.

In Gpg4win-4.3.0-beta571 with GnuPG 2.4.4-beta132

>echo test | gpg --sign --default-key F8D51DE0EE16E9B57009B8DE458612006D8E6F0D
gpg: Warning: not using 'F8D51DE0EE16E9B57009B8DE458612006D8E6F0D' as default key: Key expired
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: Unusable secret key
gpg: signing failed: Unusable secret key

It is already implemented and will soon show up in 2.4.4 -)

• To configure a keyserver none I have now T6950: Kleopatra: Usability improvements for directory services configuration
• For tarball naming I created T6952: Gpg4win build system: Include commit hash in tarballs from gen-tarball.sh
• For the about dialog I have T6953: Kleopatra: show commit id in about dialog

In T6946#181608, @werner wrote:

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

I noticed the Debian bug and was about to answer but a feature request is also a good thing.