If you want this to happen, then you should consider contributing a patch. Please see doc/HACKING for the formal requirements.

I guess we need some gpgme support as well.

How with --status-fd passed to gpgtar we will get these progress lines:

I am adding gpgcom, as a tag, the first minimal task would be to create such a page with the debug output from gpgconf -X with options to copy / or save them to a file. Not sure if that should be a subtask, because on the other hand this would be a start of this "Debug Tab"

What I need in particular is a way to get the output of gpgconf -X.

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

Let's first collect all keys, assign a priority, sort, and only then send them back to ssh.

Well, I do not yet see a use case for this. The current rush towards PQC makes it unlikely that newer curves will get in widespread use. Iff we have a large application which requires this curves, we can reconsider,

It turned out that this does not make much sense.

We can simply change the arg type from number to string and use a value like 3072/20240101

I see the use to have an option to have a stricter "min-rsa-length", and which will be useful even in the future e.g. for 4096.

I think the current way is a good compromise. Turning this into a fatal error has also resulted in very many support cases.

For testing I have created a Gpg4win installer and only selected minimal installation and gpgme-json was there. Both in /bin and /bin_64.

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

I guess we can close this one.

This overlaps with T5959: Kleopatra: Show key source in details widget if it is not unkown.

Another idea (based on above ideas): We add an optional column named "Valid For" and only list the usages that are currently possible. If the encryption subkey is expired, then the key will probably only be valid for signing and certifying. This should be easier to understand than my fancy color coding idea while still giving the user a hint what a certain certificate can be used for. I'd still abbreviate the usage to a single letter in English. Translators could still use more letters if a single letter would be ambiguous.

If you enter a wrong password in a window, the error message will only be given after you have answered all requests for the transport passwords.

No. We now ignore expired key with --mirror, --create, and --install-key.

works

Actually we have two gpgme versions in gpg4win because gnupg is a "sub"-installer inside of gpg4win and it comes with its own gpgme. That gpgme is the release version but the one used by gpg4win's kleopatra is often a newer snapshot.

Keyserver option is no longer shown in the OpenPGP tab of GnuPG System

works

I put rCc34c9e70055e: fips: Mark AES key wrapping as approved. under this task, so that it can be referred in the release note.

We need to do this also for CHANGE REFERENCE DATA - however, there should be an extra option so that we can debug this despite of the redacting.

works

The distinction between reader and card is not easy and PS/SC is also not helpful here. The user needs to resort to trial and error. With 2.3 things are much easier because we do not need to select the reader anymore.

works

Merged PIPE connection part into master.

I updated *.m4 scripts in gogol:

Hello, if I understand the issue correctly this issue is about saving a decrypted email as a file to a local disk and not to Outlook? We would like to save the mail as a file like a normal mail file.

For *.m4 scripts, I pushed changes to prefer gpgrt-config with *.pc files than *-config scripts (T5034).
Before the change, it was not coherent; gpgrt-config gpg-error is preferred to gpg-error-config (if available), but libassuan-config was used if available.
After the change, gpgrt-config is used to configure gpg-error and libassuan, etc.