Patch sent to gnupg-devel. I think this can be applied to the 2.4 series as well.

I think there's some confusion.

No real world bug reports for this and thus a backport has a small risk of a regression.

The compliance mode likes 4880 or 2440 are only here for backward compatibility in case that is needed. New keys shall always be generated using the current default algorithms. Note that a mode like de-vs is different in that it is used to comply with certain regulatory demands and not as a backward compatibility hack.

After a lot of digging I finally found the problem. It's actually not Gpg4win/GnuPG, but it's the Bitwarden desktop app. They recently added support for it to function as an SSH agent, and even though I have not enabled that feature, it's hijacking the socket anyways. When I close Bitwarden the issue disappears. The issue is logged in bitwarden/clients#13150.

changed the workboard to gpd5x as this is still the case in Gpg4win 5.0-Beta versions.

i see two forms of an initial resolution here: one is to have set_compliance_option always explicitly set opt.def_newkey_algo. The other is to check opt.compliance in get_default_pubkey_algo.

Thanks for the followup. As a downstream maintainer, it would help me a lot to know why this won't be fixed for 2.4. Do you forsee a specific problem with it? Does the subtle change in semantics of previously unspecified combinations/permutations of options represent something you're trying to avoid on the stable release channel? Are there bugs that users should be worried about?

Okay, thanks!

Fixed in master and the new gpgme-1.24-branch. Thus this fix will be in 2.0.0 and 1.24.2

Sorry, this will not be fixed for 2.4.

please prefer the patch here over the one on the mailing list. my followups to the mailing list are not going through due to some kind of intermittent IPv4/IPv6 deliverability issue. Sorry for the confusion.

Thanks for the fix, @werner ! Here's a comparable patch for the 2.4 branch as well, but without the change to de-vs as i think the comment in rGc2ff47d5bcd2953fc2095ef2242af2c7e9cd4420 indicated that you only wanted to rebase de-vs to --gnupg in the 2.5.x series.

I am pretty sure this was my fault: rM62b6c1f16 is the culprit.

@werner Thank you for the response. Is there a nightly build or similar that I can grab from somewhere to see if using the latest master branch solves the issue?

@gouttegd: Good idea. I did this with the above patches.

Thanks. I applied all 4 patches to master and did one additional change to get --allow-old-cipher-algos straight.

I never tested the WSL stuff with gpg-agent but I use the standard OpenSSH based ssh server on Windows on a daily base. It is actually part of our release build chain. A recent problem I encountered was fixed in master with rG2469dc5aae and should be backported to 2.4. Might be related to your problem but I need to read your detailed bug report more closely.

Here's all of the above patches squashed into a single patch:

attached here is a series of 4 patches that reinforce that the last --compliance policy option (or equivalent option, like --rfc4880 or --gnupg) supercedes any earlier one.

sorry for the confusion in the initial report -- the policy compliance option is of course --compliance, and not --policy, and i just miswrote it in one line of the description above. I've corrected it now, and all the rest of the report is still as it was.

That gpg seems to be some other or patched software than the one from gnupg:

This issue occurs when using GPGME with multiple contexts and setting the OpenPGP engines to different GnuPG home paths. As you mentioned, it is crucial to let gpgconf know the correct home path so that it can locate the socket file used by gpg-agent and properly clean up all instances.

gpgconf assumes that there is only one of the daemons. In fact it can only work with one and that is the one daemon which listens on the socket. all daemon's do a self-check by trying to connect to themself and terminate if they realize that they are not anymore the owner of the socket. As long as a daemon is started by a gnupg component a file system lock is taken to avoid duplicate launching. However it a daemon is stared by other means this could lead to a race.

For command line, reported issues have been fixed; Confusions for wrong errors are gone, it correctly reports appropriate errors of:

• GPG_ERR_PIN_BLOCKED
• GPG_ERR_NO_RESET_CODE
• GPG_ERR_BAD_PIN

VS-Desktop-3.2.94.481-Beta: same as for the Gpg4win version.
And there is a hint if you enter "hkps://something" that this is not the right format (that is included in Gpg4win 4.4.0, too)

VSD-Beta-481: Encrypting/signing with gpgtar on the cli and decrypting/verifying with Kleopatra works

What is the status (or maybe better scope) of this ticket? Why was it set to the milestone 2.4.5?
I do not see any improvement in Kleopatra from Gpg4win 4.4 (with gpg 2.4.7) regarding the behavior when trying to unblock a card.

Reported gnupg channel on IRC.
An ascii armored file in question was: https://github.com/syncthing/syncthing/releases/download/v1.29.2/sha256sum.txt.asc

Fixed in: rGb1857a2836c9: gpg: Fix handling with no CRC armor.

When CHECKCRC == 0 (no CRC), ->any_data was not set, resulted

	no valid OpenPGP data found.

wrongly.

works in VS-Desktop-3.2.94.481-Beta

works with VS-Desktop-3.2.94.481-Beta

Fixed in: rE0f4fe2edf5e5: spawn: Care about closefrom/close call is interrupted.

@werner I read the code of gpgme/src/posix-io.c. I understand the two points:

• For the correctness sake, the possible interrupted closefrom should be handled.
• we can share the code with closefrom case and non-closefrom case.

works with VSD-beta-478

One year later, I also did translation work for kleo and libkleo, which are pushed by Andre.
So, closing this task.

Fixed in 2.5.3.

glad it was useful!

Tested with the VSD beta 478. Works

2.2 is end-of-life.
There was one actual typo fix which could be used for master, though. Thanks.

Got a simple fix for this which does two things:

1. Correctly act upon an error from the backup file writing
2. Print a warning note.

In T2169#196673, @werner wrote:

Shall we handle this with additional retry prompts, w/o a timeout? I think this makes sense because creating keys with a backup file and a passphrase is a manual task anyway.

There is a regression due to the regression fix in rGb30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7 (from Dec 24 2015) or some related commits:

@gniibe: Please see gpgme/src/posix-io.c where we have this:

Thank you for your report.

Fixed in rA69069bc63e6b: Remove an declaration for an unused function.

Hm, this might also be relevant in GnuPG's codebase in common/exechelp-posix.c, which contains a copy of the same code (licensed differently).

Also works in VSD-beta-478

Backported for VSD 3.3