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)

Thanks for the clarification!

Right, as long as there is only one format in widespread use (based on a long existing 4880bis draft) only this format should go over the wire.
Thus, it is a matter how the key is exported. In cryptography you should never have several options - one clearly defined format is what you want. We have had enough trouble with PGP5 peculiarities but in that case their implementation had more users and thus GnuPG had to work around it. Not good, but there was no standard at all at this time.

@onickolay No sorry needed. It was me, who cannot answer promptly.

It is related in the following way:
The Gpg4win installer creates these context menu actions through the component GpgEX.
The Gpg4win installer does not support Windows XP anymore.

The problem of (2), is local side-channel attacks to ElGamal encryption.
We evaluated the impact, mainly for the use case of GnuPG; ElGamal keys are not that popular any more. When such an attack is possible, easier attacks would be possible.

The paper addresses two issues.
(1) https://ibm.github.io/system-security-research-updates/2021/07/20/insecurity-elgamal-pt1
(2) https://ibm.github.io/system-security-research-updates/2021/09/06/insecurity-elgamal-pt2

What I need is exactly ikloecker described on Linux. The point is NSIS installer gnupg-w32-2.2.27_20210111.exe (and versions above, I am sure) do not create context menu shortcut. Windows XP is not the point. Same on another Windows 7 machine. Do you need I find another windows 10 machine to test? I think it's easier to check whether the installer has that feature or not.