GnuPG 2.0 reached end-of-life nearly 4 years ago. See https://gnupg.org/download/index.html#end-of-life . Same for Gpg4win. They are not maintained and its use is very risky due to unfixed bugs. Please update to a recent version.

macOS has low priority for us and I do not want to risk any regression.

@amit: Do you say it used to work with GnuPG 2.2.27 or did it worked with an older version?

Which gpg version?
Which Python library? (gnupg is pretty generic)
How does the Python library call gpg?
Are you aware that gpg uses utf8 and not Windows Unicode?

Well, while importing you get the warning:

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:

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.

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

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).

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.

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

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..

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:

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

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

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)

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.

And well, the context area of the handle is also wiped at gcry_cipher_close time. Thus any standard use of aeswrap (open,encrypt/decrypt,close) is not affected.

Good catch. Thanks. This patch should fix the leak:

My suggestion for a combined function is a simple:

Yes, --no-keyring should enough for the subset of gpg commands which do not need keys.

Sorry, GnuPG proper has no context menu or any graphic user interface. You need to install Gpg4win for this. Regarding use of gpg by other programs: There has been no change - other programs need to use the status-fd/command-fd interface and that has always been defined as UTF-8 and not as any native codepage. Please ask the makers of The Bat what is going wrong there.

The breakaway job notices should definitely only be emitted in verbose mode. For the other things I need to check.

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.

Interesting idea.

This is a hard to solve problem in the NSIS installer: If you accidently started more than one installer they may both register files for update at the next restart. Now after the restart the file which is to be renamed does not anymore exist and thus a component or even library is not available. In this case it is GpgEX, the explorer plugin.

In the editor you find a cloud symbol with an arrow to upload a file. Use this and and the file id will be pasted at the cursos, like here

The major problem I see is that an implementation needs to add more crypto primitives to support ths curve. And we can expect that 448 will eventually get in widespread use. We already have all primitives but would inhibit the creation of minimal implementations.

I see.

Fixed in 2.3 and 2.2

The task is T5577 (which I accidently closed during triage)

(I closed this by accident)