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.

The user reported to

Generating a CSR for the standard NetKey card signing key works now, but generating a CSR for the SigG NetKey card key fails (T5219).

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

D520 is accepted by me.
If you will have another fixes, please go ahead.
Or else, I'll commit the change to master of GnuPG.

I wrote https://github.com/rupor-github/win-gpg-agent to simplify usage on Windows until this issue is resolved - it handles various edge cases on Windows.

Okay. Now since configure.ac is already touching CFLAGS, it seemed like a good place to add that additional option here. All this is guarded by a test for GCC, and since clang mimics that behaviour, it works for them as well.

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.

After some more checking: LLVM-11 introduced the same behaviour in that regard, but appearently not a pragma/attribute to override this: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html

This reminds me that I should check if kconfig_compiler nowadays supports cross compiling or add that. Back when I started cross compiling kleopatra in 2015 I was lazy and patched in the generated kconfig files. I never really saw the advantage of them but yeah it's more KDEish to use them.

This works now with 0c1bd9076958e584820fadf997ca7d8a248b6888 but needs more testing before this can be relased. It will probably be part of a Gpg4win-4 beta.

Taking since I ran into this problem while working on T5174. In Kleopatra, if one opens the certificate details of one's own keys (i.e. secret key is available), then the tags vanish from the key list.

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

Hi Werner,

can you elaborate?

Ok. I've just added with rev 69539cea316f2d2998eefbd14539f8def3fc07ab more platform specific code for userinformation so this makes even more sense.

Have you tried on the command line: "gpg --gen-key" ? Maybe this gives more helpful debug output. But in the case of "permission denied" this really sounds like a local setup issue as there are also no other reports related to this. Still I'll add the saveguard to make the check in kleo more explicit.

In T5189#140853, @gniibe wrote:

Please check following translations:

"do not detach from the console"
"do not use the internal CCID driver"
"do not use a reader's pinpad"

Those are explanation for the options to instruct gpg-agent or scdaemon, not do something.
It's not a text to users.

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?

For the context of all subscribed parties I think Werner refers to what Hockeypuck is doing: https://lists.gnupg.org/pipermail/gnupg-users/2020-December/064441.html

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

I think the option you are looking for is "--homedir" with that option on the command line you can redirect where GnuPG looks for options and keys.

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