@gniibe I have submitted D565 to change the error message on curses initialization to "Required environment variable not set"

Those "curated keyrings" and keyservers don't work together. The whole idea of automated but curated keyrings is dead end.

I am very sure that this is resolved and we support that in Kleopatra.

Thanks all. It is a bug in Win32 OpenSSH. https://github.com/PowerShell/Win32-OpenSSH/issues/1953 it is already fixed. I think the issue will be resolved after the update is shipped. I could use ssh -T git@github.com as a workaround.

Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0

This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.

Authentication succeed if I pressed enter after:PTY allocation request failed on channel 0

I try WinGPG 4.1.0, and I receive an error:
ssh git@github.com
PTY allocation request failed on channel 0

Note that in-source-tree builds are broken - see T6313

Release done

To be released tomorrow.

@raysatiro: Please re-open if you are able to give us a reproducer

Thanks. Commited to master.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.

Missed some, will post an updated patch.

I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.

Thanks for reporting. We usually test by moving the <keygrip>.key files around ;-)

Sure, but this will need adaption in FIPS mode as it fails with:

Patch using SHA1 instead of MD5.

There are other uses of MD5 and thus we can't disable it. For example gpgsm also lists the MD5 fingerprint of certificates because they are still in use at some places.

Sorry, it looks like no problem.

Implications are... you won't be possible to use new protocols introduced by newer OpenSSH:

Thanks. Adding 'PubkeyAuthentication unbound' to my ~/.ssh/config seems to workaround it for me on openssh-9.1p1-3 (arch). I don't quite follow what the implications of that setting are though.

In my cases (tested with 9.1), here are the length of data to be signed by ssh-agent (emulation by gpg-agent).

• 164 bytes: Both features disabled by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com -o PubkeyAuthentication=unbound
• 192 bytes: Unbound only by: ssh -o PubkeyAuthentication=unbound
• 298 bytes: No Post Quantum only by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com
• 330 bytes: Both features enabled (no options)

I tested with openssh 9.1. When I add -o PubkeyAuthentication=unbound, I can make the length of data smaller.

In T5931#165009, @alexk wrote:

A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:

KexAlgorithms -sntrup761x25519-sha512@openssh.com

For me ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com ... does work as well.

A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:

I've got a similar patch, but I'm not sure it's any better -- I'm adding EcDSA support for cards (via gnupg-pkcs11-scd) and with this patch I can sign subkeys and data.

The problem here is how large the data to be signed is. It is an issue of protocol design. The protocols are explained in openssh/PROTOCOL.certkeys and openssh/PROTOCOL. Unfortunately, it seems that it was designed with not much consideration for smartcard use case, so, data to be signed may be longer (than the capability of smartcard).

Sadly, it doesn't work for me. But thank you.

I managed to find a way to minimize the data (less than the one on Oct 25).
And it somehow works for me.

So what should I do now? Should I report it to OpenSSH team?

Meanwhile I have _some_ doubts that the v5 format is a good idea. It will introduce a lot of problems and thus a more lean way of replacing the fingerprint should be re-considered. Even if that means, we have to live with two kinds of fingerprints for a decade or so.

Given that the OpenPGP WG practically decided to fork OpenPGP I don't see a reason why we should keep this bug open.

Will go into 2.3.9 and gpg4win 4.0.5

Has been release quite some time ago (2.3.8 and earlier)

There is a utility named kbxutil which can be sued to dump the pubring.kbx file without any post-processing by gpg. I would check whether there are any other keys after the VideoLAN key. iirc, kbxutil ist not commonly installed; you may need to build the software yourself or copy the pubring.kbx to Linux and check it here.

Oh yes, the usual import statistics should be shown here.

Pushed the change, although it is not enabled yet (since the feature will be only available by newer libgcrypt, 1.11).

Pushed.

Pushed to master.

is there any news for gnupgp 4.0.4 release with gnupg 2.3.8?

In T5790#163980, @manonfgoo wrote:

@margirou:

Can you test the Patch, does it work for you ?

Kind regards,
Manon

In T5790#163886, @werner wrote:

[Merging didn't work]

Can you test the Patch, does it work for you ?

Here is the patch as file:

The patch applies with -p1 to the master brach, alternatively I could push a commit, but my user does not seam to be allowed to do so:

[Merging didn't work]

Attached you find a patch to this issue. This Patch sets the "keypair" attribute to the keys 0x82 to 0x95 unconditionaly.

In T6218#163787, @gouttegd wrote:

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Yes. Scute relies on those to interact with the token.

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Applied and pushed the change from @joeyberkovitz in rG3257385378bb: dirmngr: Interrogate LDAP server when base DN specified..

That sounds quite cool.

Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.

I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.