Is this still an issue?

The passage has been removed from the dirmngr man page, and I marked the gpgsm option as obsolete.

This works now, there have been many changes in how homedir is handled since then. For example 70a8584ec4389209762eb65bb77f20f7881577be and aab8a0b05292b0d06e3001a0b289224cb7156dbd, among many others.

Thanks for letting us know, but there is nothing we can do about it, so I am closing it here.

That's fine. The 2.0 branch will reach EOL in 6 months and we will
probably only do a last maintenance release. No need to backport this
fix, though.

"gpg: selecting openpgp failed: Operation not supported by device" means that gpg tried to access smartcard (expecting OpenPGP card), but it failed.

Btw, if you want to use the test script, you have to use "gpg2 --keyid-format short".

I have verified that it works fine in 2.1.21. I did not test 2.0.30, but that's very old, just use the latest 2.1.x version. gpg 1.4 also only receives critical fixes.

You should really use GPGME.

I don't think we want any behavioral changes to gpg 1.4 anymore. And in gpg2 all of this is different (use-agent is mandatory, passphrase-fd only used with batch).

No feedback for 2 years.

Still an issue in gpg 2.1.21.

I could not reproduce this on Solaris 11.3 amd64 and gcc 4.8, using CFLAGS="-m64 -O2". If you have more information how to reproduce this, please reopen.

Seems to work fine on Solaris 11.3 and gcc 4.8.

I added a new task status "Testing".

On Wed, 28 Jun 2017 15:47, noreply@dev.gnupg.org said:

What tests do you want to be done?

Fixed the PUBLIC_ARCHIVE_URL setting in mm_cfg.py. I have no idea why the other archive links worked.

According to the linked discussion forum, this was a misconfiguration.

No response.

No response for years.

Fixed in b00cf0913243ad5432e4cb859146d88b6691f9a3.

Please reopen if this is still an issue with the latest version of gpg4win.

Please reopen if it can be reproduced with a recent version of gpg4win.

What tests do you want to be done?

Which tool did you use: gpg or gpgsm? <== In-house developed Web Service that call gnupg to decrypt or encrypt

Oh, my bad. Someone on IRC said it was a bug and I didn't look at any further details.

No, that is the convention used by gpgconf. See https://gnupg.org/documentation/manuals/gnupg/Format-conventions.html#Format-conventions:

Given that we have no TESTING status, the only way I can handle this is by keeping the ticket open and add the TESTING flag. Closing a bug which has not been tested is a bad idea.

Please be so kind and explain in more detail what you did.

Fixed. Thanks.

It fails the very same way:

@werner An open ticket should mean there is something that can be acted upon. Unless you are saying that we should actively look for regressions or should actively do more testing, this ticket should be closed now. There is plenty of peripheral information that will remind us of this ticket in case more issues resurface related to this change.

If this is gone in master, please close this bug. Thanks :).

Fixed in 273964798592cd479c111f47e8ce46d5b1999d6a.

https://files.gpg4win.org/Beta/current/

Issue seems to be gone in gpg (GnuPG) 2.1.22-beta75

Additional info: I tried setting up a reproducer without using a smartcard, and it fails with no secret key similar to earlier versions

seems this was fixed along the way, then. I only tested with 2.1.18.

I can't remember either. We should swicth back to mailing lists for such things.

Anyway we should not allow empty user ids.

Any updates / thoughts on how this might be fixed?

ping

Well, can you then please fix it?

Any update on this?

1.4 has build fixes for NetBSD. Thus I _assume_ this bug has been fixed.

Unlikely

GpgOL has even been revamped 2 times since then.

According to my checkout this is at

werner@trithemius.gnupg.org:/cvs/gph

But that has long gone. I need to see where to find a backup of that repo.

No way to test on El Capitain anymore. It works on Sierra.

We now have a GPGME feature to list packets:

Libgcrypt 1.6 reaches EOL in 7 days, so we won't fix it.

With the new rndjent as used with libgcrypt 1.8 under Windows rhis can be claimed as finished.

Solution has been given: Use "gpg.conf-1" for gpg 1.4

I have tested this and it appears to fix the leak of gpg-agent processes in virt-builder, thanks.