I'm not going to keep re-opening a ticket that you keep closing. So i'm just going to state here what i believe to be the upstream intent is. If you think this is wrong, i'd love a clarification. I believe that "deprecated" means that the GnuPG project believes that an option or configuration choice should not be used, and will eventually go away.

The actual cause here was that right before storing the imported key we need to decide whether to insert or update a keyblock. For this we need to lookup the key in our database and the lookup function does the usual thing by looking at any fingerprint. This is wrong: Here we need to lookup only by primary fingerprint. This is what the above patches do.

That is not a new issue. We have the very same issue since ever. However, without keyboxd you had random results depending on the order of the keys in the keyring.

That is an installation/migration question and the warning is just a convenience thing to remind the few early users of keyboxd to migrate to common.conf.

As usual use ./deadbeef.... as the filename to distinguish it from a fingerprint.

To be clear about what's going on here, blocker.cert has simply adopted the primary keys of each certificate found in /usr/share/gnupg/distsigkey.gpg -- i think GnuPG requires each component key in its keystore to have a unique fingerprint across all component keys in the keystore. so when one certificate claims those fingerprints as subkeys, any certificate that has a primary key with a matching fingerprint gets rejected with doesn't match our copy.

I understand you as saying you won't fix the fact that the warning is not emitted during initial homedir setup. I'm not sure why that scenario is not worthy of a warning when a post-setup scenario is, but okay.

thanks for correcting that, @ikloecker. i've corrected the initial report.

Daniel confused --list-options with --dump-options. The linked completion script uses the latter.

I'm glad that inotify is already in use, that's a reasonable thing on the Linux platform.

Won't be fixed for the creation thing.

This is the old code from gnupg-2.0/agent/gpg-agent.c:

inotify is already used used on Linux to check for a lost homedir. The once-in-a-minute check should be the same as with the other daemons and has proved to be very useful. The whole thing has been discussed over and over again a long time ago and - as with other system daemon - we agreed on scheduling at the full second.

Removed extraneous space.

If you say so, i won't press this. I will just leave this ticket with an observation that even for someone who reads the source code this is not intelligible. At the top of gpgconf_list in g10/gpg.c, the comment says:

This warning doesn't seem to be complete; no such warning is produced on the first run of gpg. For example (with no ~/.gnupg):

$ man gpg
       --gpgconf-list
              This command is similar to --list-config but in general only internally used by the gpgconf tool.

In general, "only internally used" means: Don't use this yourself or accept what it does.

in combination with this patch it should be easy to modify gpgconf_list() (in g10/gpg,c) to emit compliance from the settings/cli options.

Please see the 5-patch series posted on gnupg-devel for a fix for this.

Maybe we have a different understanding of what "backward compatibility" means. if someone needs backward compatibility to communicate with someone using an RFC 4880 client, then surely they don't want to use a pubkey algorithm that isn't specified in RFC 4880, right?

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

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.

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.

I'm not sure what Kleopatra should do differently. Kleopatra relies on the error messages provided by gpgme which in turn relies on gpg's status messages.

FWIW, If a fix is really required for gnupg this will be done for gnupg26 and not for gnupg22. However, it is mostly a kleopatra issue.

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

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.

If you encounter real world certificates with these parameters we can bump up the priority.

Kleopatra has no influence on this. This does surely also happen when a new keypair is created on the command line.

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.

I think I can understand you, too much complexity.

See this comment which is related to T4538:

Werner says this won't be fixed…
Because the system can be configured to use constraints which we can't explain except in ABNF, which won't help users.

Note: The is a bug in the gnupg-w32-2.5.3 tarballs. After untaring cd to the directory as usual but then do:

rm PLAY/src/zlib/*.[oa] PLAY/src/bzip2/*.[oa]

before you run

make -f build-aux/speedo.mk this-native

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.

Fixed in 2.5.3.

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

Thank you for your report.

All applied.

Looks like gpg 2.2 doesn't emit a canceled status log message, but gpg 2.4 does if the problem only occurs with VSD but not with Gpg4win.

Installing language-pack-tr-base fixed the issue. Closing. Sorry for the noise.

In T7454#196228, @werner wrote:

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

LANGUAGE= LANG= LC_MESSAGES=de_DE gpg

Thus this should work. But it did only work when I used

LANGUAGE= LANG= LC_MESSAGES=de_DE.UTF8 gpg

Thus the whole thing is related to the configuration of locale.alias and on whether LANGUAGE is set in the environment (for me it is set to en_US:en

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

It's a bug I introduced when fixing T7309.
Fixed in rGaa36f6ae8bae: gpg: Fix key generation with existing key from card.

Right, the first process is the gpg-connect-agent (via gpgconf). I used gpg just as an example. All processes use the same code to launch the agent.

There were three parties involved:

• gpgconf --launch gpg-agent
• gpg -k ...
• gpgsm --server followed by LISTKEYS command

Thinking again about this my hypothesis is:

IIUC, simpler solution would be modifying m4/socklen.m4 adding Solaris variant specific code.
Tweaking _XOPEN_SOURCE requires the change of Autoconf (if done correctly), which would be larger surgery.

In T7434#195318, @ikloecker wrote:

I'm wondering what happened (or why nothing happened) between the exit of gpg-agent[2816] at 10:11:12 and the start of gpg-agent[6492] at 10:12:00.

I am not sure if it helps if I comment, I just saw that this is issue cropped up again, and although we might be seeing different problems since other reports like T6623: Kleopatra hangs "Loading certificate cache" on Windows 10 T4581: Kleopatra stuck in loading the certificate cache are about indefinite hangs. (Was a timeout added in a generic place recently?) I just hope that at one point the underlying cause for this is found and resolved instead of hiding the symptom each time we find a way to reproduce this a bit better. Seeing T7437 and T7438 in which I commented a bit more made me sad that this is still not treated as a GnuPG issue.