Description and translation domain were swapped in 2.2.

On Thu, 7 Jan 2021 09:56, bernhard (Bernhard Reiter) said:

We need to switch to the SigG application. Shall I look at it?

Do we need to backport to 1.8?

Do we really need this for 1.9?

What is the state of this bug? Reading is implemented - do we really need writing (maybe to support certain smartcards)?

It is possible to disable the mlock thingy and if that is not wanted the application should be modified to be suid(root) during Libgcrypt initialization - this is actually how we handle this in GnuPG. Or maybe I don't understand the bug described here. It seems to be more of a support question.

For security and auditing reasons a Libgcrypt SO may not be "unloaded".

gcry_ecc_get_algo_keylen has been added with commit a658c9ccc2c741f40b0b5cdbcd184cfb9a841d17 but documentation is missing.

Please describe exactly what you did so that we can replicate this.

Thanks. I added the OIDs and the missing curves. To go into 1.9

Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.

The C++, CL, Javascript and QT Bindings are all written by hand.

It seems you have a pretty good understanding and also test cases at hand. May I ask you to apply the suggested pacthes to master?

Given all the resources we had put on this Python bindings I'd suggest to bite the bullet and replace Swig by handcrafted bindings. More work but we do it for the other bindings as well.

I'd suggest to first try the current version to see whether the bug has been solved.

I think we can close this one, right?

Meanwhile there are simpler ideas and code on how to do only authenticated uploads. Thus lowering the prio.

@glr thanks for the offer. Right now the number of support requests is low enough that we can handle them during the normal triage.

Please try using the current version (3.1.14) and if the problem persists re-open this bug. In this case we will also need a more detailed report.

(Reporter has problems running his own keyserver and accessing it.)

Please try gpg4win 3.1.14 and check whether your problem has gone.

Flagged as high becuase this is RC for Libgcrypt 1.9

Thus better add a

&& !defined(__clang__)

Sure that the FreeBSD compiler does not define it? I am pretty sure it does.

You may want to check that clang supports this attribute as well.

I fixed the latter two points. For directories this can't be done because not only the server reads the directories but also other deployment tools (e.g. rsync).

We should see that we can implement an auto-key-locate feature also in gpgsm. This would allow us to fetch the key as needed from the AD or another LDAP server.

Use released version or post to gnupg-devel for help.

Please report about released versions. If you have problems building from Git, posting to gnupg-devel is the best way forward,.

When building from git make sure that you have all tools installed and use
./autogen.sh --force
before running configure. Do not use autoreconf etc.

GnuPG requires some C99 features - thus a language level of C89 might not work. We use variadic macros and the func macro. For details see doc/HACKING.

The patch will be in 2.2.27. Thanks.

Simply add -v or --verbose to the gpg invocation too see infos about the pinentry. --debug-level is not helpful here.
And well, we don't have a way to test stuff on Vista anymore. You should also update to at least Windows 7.

Good catch. This is due to back porting a change from master. However the extra introduced conditional of

if (sig->version >=4)

will always evaluate to true. It is set a bit above and GnuPG does not handle public key packets with version 3 anymore. So this if can actually be removed. Thus no harm.