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.

Reading compressed point (in keys) is supported (except for NIST P-224). When curve point is represented in compressed format, it is correctly interpreted now. So, for example, I think that with 1.9.0, gpgsm can handle certificate which uses compressed format in its curve point representation.

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

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.

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

Hi Werner,

can you elaborate?

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

Actually this isn't really a special case when you want to migrate your existing ssh keys to gpg and import them. As stated in this guide https://opensource.com/article/19/4/gpg-subkeys-ssh-multiples, what you need to do currently is export the master key with its private keys, delete the imported ssh key from your keyring and then import your private keys again.

Werner, please retest. If "Change Reset Code" still doesn't work for you, then please answer the questions in the first comment.

Note: Officially, Kleopatra does not support OpenPGP v1 cards. At least, according to the text that is displayed if no card is found.

"Change Reset Code" should work in Kleopatra. At least for OpenPGP v2+ cards. Kleopatra simply does "SCD PASSWD --reset OPENPGP.2", i.e. the same as gpg-card. I have verified that it works with a Yubikey.

If your problem is the incompatibility between standard OpenSSH (server) and PKIXSSH (client) for use of ssh-agent emulation of gpg-agent with ECDSA key, I'd suggest to apply following patch to your PKIXSSH:

diff --git a/compat.c b/compat.c
index fe71951..0c9b1ef 100644
--- a/compat.c
+++ b/compat.c
@@ -245,7 +245,6 @@ xkey_compatibility(const char *remote_version) {
 {	static sshx_compatibility info[] = {
 		{ 0, "OpenSSH*PKIX[??.*" /* 10.+ first correct */ },
 		{ 0, "OpenSSH*PKIX[X.*" /* developlement */ },
-		{ 1, "OpenSSH*" /* PKIX pre 10.0 */ },
 		{ 1, "SecureNetTerm-3.1" /* same as PKIX pre 10.0 */},
 		{ 0, NULL } };
 	p = xkey_compatibility_find(remote_version, info);

Unfortunately and confusingly, PKISSH returns "OpenSSH" when asked by "ssh -V".
Please install real OpenSSH, if this is the case for you.

Quote from IRC:
hey, i've some problems with my smartcard since quite some time. i'm not sure whether it's openssh related or gnupg. it's a openpgpcard v2.0 and i have to workaround ssh logins by using "SSH_AUTH_SOCK=0 ssh ...". .gnupg/gpg-agent.conf -

Yeah but it seems to be the same issue / reason. I wasn't aware that PKISSH is something else. I thought it was an extension/protocol or something

I added "Feature Request", because this is a request to support:

• A feature of bug compatibility, which is implemented wrongly in PKISSH
• for a specific algo of key, which is not considered so useful (== ECDSA)
• PKISSH, which is variant of OpenSSH

In T4563#140184, @idl0r wrote:

I was and I am using OpenSSH on both sides, client and server.

I was and I am using OpenSSH on both sides, client and server.

I do not think that we should support a fork of openssh right now. If we would support it we are bound to maintain that for years - this is not a good idea.