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.

Yep. Closed now.

Will go into 2.3.9 and gpg4win 4.0.5

You are using a somewhat special setup and not what has been tested with gpg (i.e. putty). In particular Cygwin based tools do not interoperate well with non-Cygwin tools.

@jukivili: This has been released with 1.10.0 - shall we close this bug?

Shall we really backport this to 2.2 given that ECC for S/MIME is in most cases a smartcard thing?

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

Will be released with 2.3.9

@aheinecke Please show me how you configure your libassuan-master (and the output which detects host's gpg-error-config erroneously).

I have pushed the patch, but still it did not work for me properly over everything and I had to add --enable-install-gpg-error-config to libgpg-error. This was because of at least the 64 bit build of libassuan-master it picked up gpg-error-config from my host system. I then tried to add --with-gpg-error-prefix to the assuan call but that failed because it only looked for gpg-error-config in this prefix and not for any gpgrt-config and failed immediately with a command not found error.

works as proposed by werner.

Go ahead if you want to do that.