Hey @wener.. As I mentioned in the original post, there's a default-new-key-algo setting... Is it still not possible to use specify something like "rsa4096/cert,rsa4096/encr,rsa4096/sign,rsa4096/auth"?? Would love to see some progress on this. Glad to help test.

The flag value is now 144 and not 146, but that extra bit (value 2) did not make sense for the option. So I think things are okay now.

Given that all subtasks are at least in testing state, we can close this bug.

and item 6. Now for more testing.

Maybe have gpg-wks-client(or also --export-filter) print a warning if the filtered result has a key expiration different than the original key? That seems the simplest way tp approach the problem.

Items 1 to 5 have now been resolved.

That it. Things works nicely for me. Won't be backported to 2.2 because this introduces minor changes in the behaviour.

So we now get UTF-8 argv in all GnuPG modules. Globing has been enabled for gpg using our own globing code instead of the ASCII only "int _dowildcard = 1;" mingw way.

The show error is due a missing translation. What happened was that the translation was marked fuzzy and this marker was removed not realizing that the string really changed. The change was "...in the GnuPG system" -> "...in the %s system" which had been done to allow for different gpg names.

Start from scratch on a german system, even when you do a gpg --version it shows it is in german. Then import a PKCS#12 container and the dialog is in english.

A wild guess is that the different envvar systems we have in use are the culprit. It is anyway time to get this straight.

Note that the backlog at https://dev.gnupg.org/tag/gpg23/ has quite some items and it is not yet clear which we will implement/fix first.

For 2.3.0 we won't be able to fix all bugs./feature requests. Instead we l will solve that in the 2.3 series.

Works for me.

dirmngr needs to be killed for this. gpgconf --kill dirmngr.

Meanwhile we introduced the keyboxd which should solve such problems. It will be marked experimental in 2.3 but I expect that it will soon be used as the default way to store keys - at least under Windows.

Won't be done because the expectations of users are different on whether they use ssh-agent or gpg-agent. And it breaks scripts

I would not all this an accident.

We have the --unwrap option which already does this. The problem here is that an addition compression layer is not removed. Therefore I will rename this report to add a feature strip things down to a signature or literal data packet..

Eventually we will move to keyboxd which is already an experimental option in 2.3. Thus we won't do anything here.

The gpg-card is more flexible than the old gpg stuff. If there is something missing we will add it over time but it does not make sense to keep this request open.

Due to better working timeouts we have mostly soolved these problems,. Further keyservers are not anymore of great use these days.

The other patches don't make sense because of future plans for dirmngr.

Thanks for the fix.

pubkey_cmp should be symmetric (pubkey_cmp(A,B) == - pubkey_cmp(B,A)), but it was not.

The problem persists when using keyboxd which returns keys in a different order.

I'm slightly against a backport as this is a behavior change for example KMail and GpgOL which use the --sender option might get different results after this change. I don't think it would be problematic but as said I have a slight preference against backporting because changing behavior of existing calls is better something for the new major release which is in its final steps for release anyway.

In T4735#135315, @werner wrote:

Shall we backport this to 2.2 which is our LTS release?

Thanks for the reports. IIRC, we had similar reports in the past either here or on a ML.

The code has been reworked to also support the updated schema which also stores the fingerprints and a parsed down mail address. See gnupg/doc/ldap/ . These changes are in master and 2.2.26. Sorry for taking so long to fix that.

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.

Reading the code again, I think that some configuration of NKS card doesn't work well, when it has no certificates but keys (e.g. IDLM config).
I'm going to fix do_readkey as well (the approach #1).

In T5150#140039, @gniibe wrote:

With little (mostly no) knowledge of NKS card, I think I fixed this issue.

Thanks a lot for your time to locate the problem. I took the approach of #2.

I'm not sure why I thought that it would work now. With current master I get

$ gpg-connect-agent "SCD READKEY --info-only -- 39400430E38BB96F105B740A7119FE113578B59D" /bye
ERR 100663414 Invalid ID <SCD>

And I also did a backport to 2.2 :-) See rGa028f24136a062f55408a5fec84c6d31201b2143

Go ahead (but w/o the /*if (keytime*)*/ line ;-)

The following (probably not entirely correct) patch fixes the problem because it marks the PIV card key as pCARDKEY even though keytime is 0.

diff --git a/g10/keygen.c b/g10/keygen.c
index b510525e3..03c929c0b 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -4720,7 +4720,8 @@ quick_generate_keypair (ctrl_t ctrl, const char *uid, const char *algostr,

The error comes form using READKEY which is processed by gpg-agent. At this time the agent does not yet know the stub key and thus returns ENOENT. At the places before we used "SCD READKEY" which works directly with scdameon and does not need a stub file. We need to review the new(?) way of creating stub files, describe that and then fix this by either making sure tha the stub key is created first or that we use SCD READKEY there too.

Seems to work now. I'm not sure whether I should close this issue because it's marked for backport.

Works now. Thanks.

Regarding a backport I think that I will eventually backport all app-*c to stable by source copying them. We have a quite stable internal API and thus it is easier to keep at least the card specific code in sync. I did some local work in this directory some time ago.