We need to figure out why the file locks seem not to work. gpg-agent processes whatch there own socket and terminate if that socket does not belong to them anymore.

I checked two devices and both have the info below but 332 on the case.

Bus 001 Device 123: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader

Okay, I have the same problem at my office and thus I should be able to figure out the reason. I have ignored the problem until now because the wokraround is easy enough and in most cases I authenticate with my token anyway. But yes, this needs to be fixed.

I assume this is the Windows version. gpg uses a locking mechanism to avoid creating several gpg-agent processes. In the worst case this may take quite some time until one of the processes can get the lock. There is an exponential backoff scheme in use and I have not yet found a way to replicate the full deadlock you describe. It would be helpful if you could describe in more detail how you run into this case.

Using a not yet existing directory is a security feature. The directory is created at a time the signature has not yet been verified and thus it would be too easy to trick a user into overwriting important data.

Thanks for the detailed report. Does the green LED blink fast when it does not work?

Are you using libgcrypt 1.8 or master (to be 1.9)?

It should be possible to apply the patch rG7de9ed521e516879a72ec6ff6400aed4bdce5920
for 2.2 also to older 2.1 or 2.2 versions,

That keeps the group permissions of an existing directory. Needs to be backported to 2.2

The fix we have there has the problem that it forcefully changes the permissions. Consider the case that for example that group access was provided which will currently be reset with each start of gpg-agent.

Checkout the taskbar. While creating the key you should get a (blinking) notification for pinentry - the tool to enter the passphrase. Under some circumstances Windows won't pop up that tool and you need to click on its icon in the taskbar.

@gniibe: Actually I implemented this recently. Support for this is in gpg-card

On an OpenPGP card the key no 1 (OPENPGP.1) is a sign-only key - you can't use it for decryption even if you somehow managed to encrypt to that key. That restriction is enforced by the card.

Your problem seems to be that you don't have a copy of your public key anymore. The uni-mainz keyserver might be configured not to return expired keys (if I read the output above correctly). I was able to to retrieve your key using the standard pool (in particular from the server sks.pod02.fleetstreetops.com). The key is expired but that does hinder you to decrypt. Run "gpg --card-status" once tomake sure a stub file is available.

Last week:

• Security Fix handling

I will consider a -p option for gpgtar.

See
https://lists.wald.intevation.org/pipermail/gpg4win-announce/2020-September/000089.html
for the fixed Gpg4win 3.1.13

Gpg4win 3.113 has also been released. Thus closing this issue.

Winepath starts calls the full Wine engine just convert file names to DOS format. This is used by libtool but if winepath can't be executed, it doesn't care. So the given solution (using /etc/alternatives/winepath -> /bin/false) can be used.

Small correction: The fixed byte I talked about may have the values 1, 2, 3, or 4.

Unfortunately you can't pass extra arguments.

This has CVE-2020-25125

2.2.23 has been released and announced.

The fix will be in the 2.2.23 release (T5045).

To implement this it would be best to have an gpg_strerror variant which does not call dgettext.

re 1: Correct utf-8 truncation would be quite some work. In this case the message is in the Assuan interface is a debugging aid. Translation is not necessary so we can try to disable it.

You need to get you toolchain correctly installed.

A bug was reported against this version which could happen also to older versions of GnuPG 2.2. In case of a crash please apply the patch over at rG8ec9573e57866dda5efb4677d4454161517484bc or wait for 2.2.23

See https://bugzilla.opensuse.org/show_bug.cgi?id=1176034 for the original bug report. I was not able to replicate the crash but the bad reads. The error is pretty obvious: The code expects that all fields are zeroed out.

gpg-agent has only very limited support for ssh certificates which is the reason that your command fails.

I should add a test with Gnuk to my Windows quick test after a release.

There is not a lot of demand for this, thus we have not continued to think about it.