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.

@ilf: Yes these message are emitted using log_info in 2.4.7 and 2.5.2. Thus they don't case a failure exit. I will silence them with --quiet in 2.5.3.

I have created two subtasks for the two changes we could make in Kleopatra to avoid the gpg-agent startup race.

Neither gpg nor gpgsm start gpg-agent if the keyring is empty. That's why Andre made Kleo start gpg-agent explicitly so that people could get going with an empty keyring after inserting their (PKCS#15) smartcard.

Kleo needs this only because it wants to directly talk to gpg-agent via Assuan. For example to get smartcard infos. What about delaying this part until you have received some data back from gpg or gpgsm? This makes sure that the agent has been started.

Yes, that's what happens. I did an experiment with waiting for gpgconf --launch gpg-agent to succeed, but the timeout of 5 seconds I used was too low and I didn't feel like increasing the timeout. Instead now we run gpgconf --launch gpg-agent detached.

Let me guess: Kleopatra starts the agent using gpgconf --launch gpg-agent which in turn uses gpg-connect-agent to actually start the agent if needed. Kleopatra does not seem to wait for the launch to succeed and fires up gpg and gpgsm. They both wait for the gpg-agent to be started and both use the same locking strategy. However, this involves a pseudo random wait which should avoid deadlocks. See gnupg/common/dotlock.c:next_wait_interval