Oh sorry I only saw this now. We have "gpgme_set_offline" for this use case which disables CRL checks in the S/MIME case. It is more general because it also disables OCSP for example and might disable more online actions like fetching chain certificates etc.

Understood. I appreciate the time you took to analyse the issue. Thanks.

Indeed. The called function dates back to 2004. We really need to rework this and cache the value - it might be required to take the file_name into account.

@werner I saw the call in _gpgme_set_engine_info at line 452 https://dev.gnupg.org/source/gpgme/browse/master/src/engine.c$452 which I think leads down to _gpgme_get_program_version in version.c which does a spawn and uses no cache.

I had the same suspicion andIchecked the code. afaics all values are taken from a cache (see dirinfo.c). Thus no real overhead.

In T6369#167642, @werner wrote:

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

That's what I was initially trying to do, but then I saw https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=src/keylist.c;h=1c01bd42b8497932d218e4d525794ed98e712bf5;hb=HEAD#l1362 and I wasn't sure if I needed to copy that logic to avoid introducing any regressions.

If you got a limited list of, say, fingerprints, you should put them into an array and use gpgme_op_keylist_ext_start tolist only those keys. This will be much faster.

In T6369#167649, @ikloecker wrote:

Finally, what's your use case? gpgme_get_key() is meant to be used for getting individual keys. It's not meant to be used to get 1000 keys in a loop.

If you mean gcc optimization flags, then yes.

Finally, what's your use case? gpgme_get_key() is meant to be used for getting individual keys. It's not meant to be used to get 1000 keys in a loop.

Moreover, if you have performance problems on Windows, then it's not the best idea to strace the code on Linux.

Just asking the obvious: You are using an optimized release build for your benchmarks, right?

Benchmark script:

yeah, I'd guess it's creating a new gpg instance with it. strace shows extra clone/pipe/read/fcntl syscalls with the new context.

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

Output of --show-configs should also be added as a button or directly visible when the selftest of Kleopatra fails.

I try experiment using Python PKCS#11 (https://python-pkcs11.readthedocs.io/en/latest/index.html)

• with SoftHSM https://github.com/opendnssec/SoftHSMv2
• with Scute

I concluded that (at first, for the initial try) it's not good to start this under scdaemon, because of two different abstractions for accessing the device (the way of scdaemon and the way of PKCS#11).
It's good to start with something like tpm2d. The goal would be integration into scdaemon or tpm2d.

Nobody stops you from removing any unwanted keys from the keyring. Nobody stops you from importing all keys to a temporary keyring (using a temporary GNUPGHOME), export only those keys you want in your proper keyring, import those in your proper keyring, and then ditch the temporary keyring (resp. GNUPGHOME). gpg doesn't stop you from doing any of this.

Well, I think it's a matter of taste what keys a user wants to have in which keyring. Some users want only the keys they actually use.
I think policy or the algorithm should not take the decision away from the user. "Free software for unfree users" doesn't make much sense. Maybe I'm just so old that I still think the computer should do what the user wants it to do, and not the other way around (which seems to be a current trend).

It does not matter what you have in you keyring. It does not harm to have arbitrary keys there.

See the the commit for a description of the changes.

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