I just realized that my example is incorrect. It doesn't make sense to support multiple issuer subpackets on self signatures. But it is useful to do so on binary signatures and third-party certifications. Here's a better example, which gpg correctly supports. As such, this issue should be closed. Sorry for the noise.

aheinecke: I agree, we should not port everything back just because we could do that.

This has been released with 2.3.0 and no relevant problems have reported in the last two weeks, thus closing.

t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.

the t-link test should dlopen scute.so in runtime rather than link against it in build-time.

As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.

For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:

Making this task up to HIGH priority, so that people can easily find this change in 2.3.0.

In T5394#145082, @werner wrote:

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

Done for 2.2. and 2.3.

Done in 2.3.0.

Done in 2.3.0.

Done in 2.3.

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.

Looks good to me, it no longer returns immediately with the error when there are no readers and the command itself seems to work. Thanks.

Ah, I see that when there is no card reader, it returns "Service is not running" with PC/SC.
Let's fix that.

When testing under Windows "scd devinfo --watch" returns immediately with ERR 100663614 Service is not running <SCD>
Probably also if you would use PC/SC on Linux but I have not tested this.

I was also somewhat surprised to see that the max-cache-ttl options were rendered ineffective my moving the keys to a card.

Thanks for the Gpg4win praise; however we don't have the required resources yet to take this up.

New option --force-sign-key for 2.2.28 and 2.3. Also added support to gpgme.

Pushed to master with two commits:

• https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=440332532a1c107e2baeafda5464e0707f634be1
• https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=760ef8baee06db5ce4da55eb5648e605aa511d2d

Actually we considerto remove this feature from the GUI because with the global config we have a more versatile feature now.

and item 6. Now for more testing.

Following @turkja 's advice, here's a python script I wrote that does exactly that:

Fixed typos and applied to master. Thanks.

Items 1 to 5 have now been resolved.

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.

In T5286#143493, @shaoyj wrote:

Excuse me, where is the link to this blog you mentioned?

@bobwxc wrote:
And I found a blog seems written by the SM2 implementation author of libgcrybt -- Tianjia Zhang. He/She drew a red circle on a standard picture of the Z_A.

Excuse me, where is the link to this blog you mentioned?

In T5286#142947, @werner wrote:

We need more information on the why and when of this change. We don't want to maintain different versions of the same algorithm. The I-D expired more than 6 years ago and thus it should not be used as a reference.

I'm sorry, if my wording sounded harsh.

In T1756#143328, @gniibe wrote:

In T1756#131862, @whites11 wrote:

I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

??? Do you understand how ssh keys are handled by ssh client and ssh-agent?

In T1756#131862, @whites11 wrote:

I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

Could you tell what is the status of this ticket? Is it planned for the development?
For some users usage is problematic when there are other readers recognized, provided by the OS or hardware platform, and ordered before the target device which in turn blocks access to it.

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

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.

We need more information on the why and when of this change. We don't want to maintain different versions of the same algorithm. The I-D expired more than 6 years ago and thus it should not be used as a reference.

https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02
Section 5.1.4.4

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?

provided Info by comment from 20201003: please remove Tag "Info needed (Backlog)"!

Hi,
you can close this tickets, the Italian translation has already been uploaded successfully. Don't import anything to GnuPG. Thanks a lot!

No disagreement after more than a year, I think it’s fair to say that either everybody is fine with that feature being only present in the -qt, -tqt, -gtk, and -curses pinentries, or that nobody cares. :) Closing now, will be part of the upcoming pinentry-1.1.1.