Yes, for migration from GnuPG 2.0 reasons, a batch import delays the key checking (i.e. converting from OpenPGP to GnuPG internal format) to the first use. Thus you don't see an error immediately. But if you encrypt something , you won't be able to decrypt it again:

Thanks, Werner.
During further work on this got another issue:

FWIW: I tested it with a freshly created card and thus keys. When hitting the "create OpenPGP Key " button, a warning was shown that a key already exists, I selected the do-anyway thing but the created keys had different fingerprints then. Thus the creation time was not taken in account. I recall that I implemented this for gpg-card and thus only for 2.3 - it is just quite likely that it does not work for 2.2.

I thought that I had tested this with some 2.2.x version of gpg. But if it doesn't work with 2.2.31, then I probably didn't and just relied on the release notes.

Hmm, I had removed a stretch there because I thought that a stretch in the middle of the dialog looks bad. Usually, vertical stretches are added just before the button row.

Thanks. Applied with a minor change: The string is now in a new third field.

Thanks for reporting. However, many gcc warnings produce a lot of false positives. Thus to be useful all the warnings need to be scrutinized. Let's do this for one example

OK, while I'll be awaiting for anyone to possibly answer my last T5593 'Sat, Sep 18, 6:29 PM' question, just for sake of completeness I've also been able to check that inside registry (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Gpg4win\kleopatra\Capabilities) Kleopatra icon has correct expected value so ApplicationIcon (REG_SZ) = 'C:\Program Files (x86)\Gpg4win\bin\kleopatra.exe,0' (N.B. preceding text string into registry is obviously unquoted ). ;-D

OK, while I'll be awaiting for anyone to possibly answer my last 'Sat, Sep 18, 6:29 PM' question that I decided to re-update today, just for sake of completeness I've also been able to check more inside registry but details will only go inside T5605 since only pertinent there ;-D

Because of T3458 and other references to PATH I found in the past (see past references I added previously into this bug), could anyone please be so kind to confirm me if am I right to assume that under normal conditions (so with no PATH related errors like 'PATH env variable too big' I reported here) after proper end of 'gpg4win-3.1.16.exe' installation only following (unquoted) path string 'C:\Program Files (x86)\Gpg4win\bin;' would have been added at beginning of PATH system environment variable ?
Or if not, would new path rather have 'C:\Program Files (x86)\Gpg4win\bin;C:\Program Files (x86)\GnuPG\bin;' (always unquoted) prepended at beginning of PATH system environment variable ?
P.S. Please note that I'm only asking this to then try to properly manually set PATH system environment variable accordingly and then see if my (current) 2nd 'gpg4win-3.1.16.exe' installation can still work correctly as expected or not... ;-D

Woops, I also forgot to say that only Kleopatra icon I found on my desktop has this problem. Original folder path of Kleopatra.lnk shortcut I have on my Desktop is C:\Users\Public\Desktop.
While 'Kleopatra.lnk_' I uploaded after renaming its extension as 'lnk_' was just another copy of it I temporarily put on my own Desktop only for uploading.

I have a draft, which results in the following "API" of the name-version:

The actual patch is rGd4768bb982adb5c8410303334ee8d82ba0d71f3b (our parser in dev.gnupg.org missed to pick up the bug-id due to teh use of scissor lines in the commit message).

I had in my mind something like this:

The changes do not seem to touch anything I've mentoned in (1)?

I see, I wasn't aware of this. Thanks for fixing!

While data template preparation for RSA-PSS is a bit tricky, it's simple with ECDSA.

Tried and no change -- cmd window still flashes away.

Thanks for commenting. I close this bug then.

Remember to always pass --batch for unattended operations.

Having hash-algo in the s-exp is useful because a hash handle may carry several hashes. This is sometimes useful if you do not know the hash algorithm in advance and you need to make a guess (various PGP compatibility things in gpg). But of course we can simplify this and use the default algo from the hash handle if hash-algo is missing.

Thanks for your comment.

Thanks for the explanation. I understand gnupg-w32 is mainly for installing the command line component, yet adding a context menu for a specific file type is just as simple as importing a reg file like:

Thanks to jaclaz@msfn.org, the workaround is to use pipe operation like:
pause|"C:\Program Files\GnuPG\bin\gpg.exe" --verify "%1"
He also confirmed that gpg.exe does interrupt batch processing, regardless what command is followed.
And I have tested in Windows 7, batch processing is not interrupted. Since this bug is WindowsXp specific, "won't fix" should be more proper.

Your proposed fix (in your first comment) has actually already been applied (commit 1305baf0994059f458b1d5ca28a355c12932fab3 in master, backported to the -2.2 branch in 455ba49071dea7588c9de11785b3092e45e4560b). It is part of gnupg-2.2.31 released today. :)

The Qt upstream bug report has just been rejected. I hope something can be done here...

We ran the coverity again with the new 2.3.1 release and there are couple of new stuff that I probably missed in the initial review.

I introduced a regression in this version; if you run into problems please update to 2.3.31 (T5571)

Thank you. On the first sight, it looks reasonable, but I would like to experiment with it a bit to see all use cases are covered.

Thanks. I think we are good here. If we will decide to pursuate the brainpool switch, I will open a new issue.

Some quick ideas: On Windows we have envvars (and APIs) to determine certain locations. There is also the registry. We use of all them. IT would be best to do this simalar on Unix. We also have a control file on Windows which switches to that portable mode; maybe it is best to do this also on Unix - A text file installed alongside gpg which gpg (common/homedir.c) uses to enable the use of certain envvars to locate the root etc..

Pushed my initial implementation: rC117f5c3f8028: experiment-pk_hash_sign/verify: Implement pk_hash_sign/verify.

I am doing an experiment to implement gcry_pk_hash_sign.

Two third patches are applied to master. (@werner those parts are typo fix and tests improvement, which we agreed to push.)

We can easily extend the gcry_get_config API. You can give a key or have it to return all infos. For examle
"gpgconf --show-versions" prints this about libgcrypt:

One challenge of the AppImage is how to make gpg and its helpers use the helpers baked into the AppImage. Currently, everything is built with prefix /build/AppDir/usr. This causes

gpg: failed to start agent '/build/AppDir/usr/bin/gpg-agent': No such file or directory

unless gpg finds an already running agent.

If a configure switch to disable Brainpool curves will be added, we also need to add a switch to disable NIST curves.

Oh, my bad. I probably used wrong git command. Uploaded now the patches themselves:

disable-brainpool.patch is a text of list of patches.
I think the first two could be applied.
@Jakuje Could you please upload them?

Thanks. I meanwhile pushed a fix to 2.3 so that a warning is shown if the low bits are set.

Thanks for the replies, this makes things clear. We'll update RNP to correctly set/unset those bits while saving a generated secret key and a way to fix up previously generated keys.

Won't be implemented as a new option because --check-sym-passphrase-pattern and --check-passphrase-pattern (since 2.2.30) can be used to implement the same in a more flexible way.

gniibe: What's the state of this?

Currently I see no need to fix this for 2.2

Released with 2.2.30 (T5519)