Also required for an actium feature with UI.

Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.

Thanks, I confirm that this new commit is fixing the issue.

I'd also be interested in expanding tilde expressions for dotfiles portability, since I don't use the same username in all my machines

Thank you for testing. Now, I can see the exact reason by your npth log.
Pushed another change: rPTH75c68399ef3b: Fix previous commit.

Build is still failing even with this commit, here is an extract of npth log:

Please test with: rPTH01f03a91c9bd: Return a run-time error if npth_rwlock_timedrdlock is not supported.

Could you show us the build log of nPth, please?

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.