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)

You could use --disable-keyboxd which should fix this. However, there will eventually be no more way to build w/o Sqlite and thus I would suggest not to allow disabling of sqlite.

Thanks. This has already been fixed in July with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e

Yes, we read up to the first LF. This has been the traditional way of PGP2 and is still used by mail programs like Mutt.

I see that problem but gpg has traditionally not interpreted the passphrase in any way. Right, for Windows we could strip the CR but I fear that this might break other users scripts/passphrases. However there should be a warning in the manual.

gpg verifies the content of the file and not its meta data (file name). Thus an empty file is identical to a non-existing file. The OpenPGP protocol does not allow to distinguish between a detached signature and an embedded signature if you sign an empty file.

Aihhh, my fault. seems that a new version it not too far away.

We will look into it but nevertheless I have to remark that this this portable thing is dangerous to use and you should avoid it.

Not at all. But 2.1 was such a large change that users really should have read the announcement and think about their use case. We have exensivly communicated the changes and can expect that users test their new installation. IF you have further comments, please use the mailing list.

You can write your own pinentry script instead of the loopback thing. The use the envvar PINENTRY-USER_DATA to communicate with the pinentry.

The option has been removed form the repo more than 11 years ago and the gnupg with this changes (2.1.0) was released 7 years ago including an extensive writeup on all the major changes including notices that the secret keys will be converted and moved.

I wonder about the spelling errors. For particular

Please show us the output of

Is there another way to to detect your card (I assume a Javacard) without relying on the openpgp card application vendor-id like we do it with the Yubikey? I want to avoid a possible early but expensive AID selection just to get the vendor-id.

It is quite likeley that things don't work on a non-released Windows version. We have not tested with the released version but some of us already tried Windows-11 and the gog4win development versions do work. Please wait for the next Gpg4win version or an update of the Windows-11 preview.