ggp-agent has no support for U2F and it can't work with these key types. Given that Yubikeys also have proper keys (even eddsa) I doubt that we will implement support for ecdsa-sk OpenSSH feature any time soon,

Some ideas:

• the someflags thing will probably just be a reserved parameter
• If DATA is not NULL but an MD is set the sign function should fail
• Should ownership of MD be moved to the CTX?

In an email from @werner couple days back, I got a suggestion that we could use hashing tied to the context, rather than this one-shot call tied only to digests. I circled back this suggestion to Stephan and he confirmed that it should be fine from the FIPS point of view so I am posting the suggested API here too:

ctx = gcry_pk_new (someflags)
md = gcry_md_open (...)
gcry_ctx_set_md (md);
gcry_pk_sign_ext (ctx, result, data, skey)
[...]
gcry_ctx_release (ctx);

OK. I think that the patch at SUSE is updated one which works.
As I understand correctly, this is a kind of very old patch, which intended to work around old libgcrypt limitation of RSA PSS.

I think that {D1476} is still a sketch (not real code which works). I would guess an intended use, but it's good to have concrete example program which uses the feature being added.

FWIW, there is also this newer patch: https://dev.gnupg.org/differential/diff/1476/

Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.

Does the patch really work, or is it a sketch to describe the intended use?

The private key contains the public key. Thus there is no need to export the public key if you already got the secret key.

There is also the issue that options flagged as ignore or forced in the global config file won't have an effect either. But indeed we could mark them as non-change.

I did a new test and found that if it is a single file regardless of disk size, no error appears, but when there are multiple files in a single encrypted folder with a size greater than 1.5GB, the error occurs. Traverse a directory like Zorvek and Aheinecke wrote would be an optimal solution or at least some alert messsage to be aware of the action no supported.

I have allowed myself to edit this task to more reflect what this is about. Although the error is of course in my opinion more of a bug because it is so bad but I would rather fix it with this feature.

I actually agree that this makes sense. I mean at least Kleo could say: "Hey we have detected 50 files that are encryped in this folder tree, do you really want to decrypt them all?"

GnuPG (more precisely gpg-agent) does cache the password for some time in memory. The default is 10 minutes. Add

default-cache-ttl n

where n is the number of seconds to cache the password, to ~/.gnupg/gpg-agent.conf.

Update:
It looks like OpenSSH version 8 now supports ssh-agent's handling REQUEST_IDENTITIES.

I just realized that my example is incorrect. It doesn't make sense to support multiple issuer subpackets on self signatures. But it is useful to do so on binary signatures and third-party certifications. Here's a better example, which gpg correctly supports. As such, this issue should be closed. Sorry for the noise.

aheinecke: I agree, we should not port everything back just because we could do that.

This has been released with 2.3.0 and no relevant problems have reported in the last two weeks, thus closing.

t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.

the t-link test should dlopen scute.so in runtime rather than link against it in build-time.

As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.

For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:

Making this task up to HIGH priority, so that people can easily find this change in 2.3.0.

In T5394#145082, @werner wrote:

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

Done for 2.2. and 2.3.

Done in 2.3.0.

Done in 2.3.0.