When I test it on Debian, disabling by,

Please get log of dirmngr, by putting

log-file /run/user/<YOURNUMBER-LIKE-1000>/dirmngr.log

Can you characterize the failure when ipv6.disable=1 ? The straightforward failure (connect() fails with EHOSTUNREACH after a few seconds) should presumably be treated the same as if some other host happened to be offline. That should result in dirmngr failing over to the next available address for the configured keyserver, right?

I agree with you that a certificate with a lengthy expiration is not cryptographically sensible or wise, @bernhard -- i'd never want to produce such a certificate myself.

Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.

This issue, as well as T4766 has the challenge that there is a disagreement about the usefulness of the use case, as far as I can see.

What do you mean by grep_options?

estream_t does not necessary work with stdio or posix calls; that is an implementation detail. For example if you use the mode flag "nonblock" Read/WriteFile are used on Windows.

I think the feature is not (yet) supported on Windows.
Please see: T3883: Add Win32-OpenSSH support to gpg-agent's ssh-agent

Pushed to master as rGa763bb2580b0: gpg,agent: Support Ed448 signing..

While the initial agent hang problem might be rare, it nevertheless does make sense to have a workaround for this in any case. Especially since it may not be possible to patch this effect away. The commands given by Werner provide this workaround nicely if gpg-connect-agent hangs.

These are very nice commands which I had overlooked. My results:

Update to [rGc94eea15d}.
Hash defaults to SHA512.

You may start the gpg-agent by hand:

In T4978#135418, @werner wrote:

The 5 second timeout is to give the agent time to get ready and accept connections.

The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.

The 5 second timeout is to give the agent time to get ready and accept connections. I can't say with this infor why it takes longer at your site. Can you please try without putty support?

Minicloud is up. I found that the altivec flags are never passed when libgcrypt is compiled big-endian.

I am using Duff's device which is not in that version (and makes it considerably simpler), but it certainly is influenced by that version (and the preprocessing of the table taking advantage of the communicative nature of carryless multiplication is novel in that version), and I can add a note to that effect.

Just one question at the moment.

(1) Has no (flags eddsa) in key in SEXP.
(2) Has no (flags eddsa) and no (hash-algo shake256) in data to be signed in SEXP.
(3) Has no (flags eddsa) and no (hash-algo shake256) in data to be verified in SEXP.
(4) Uses SHA256 for hashing of OpenPGP data

Update to rG4bdade5b0bea: agent: Use get_pk_algo_from_key.

Thanks for the new version. Unfortunately Minicloud seems to be down and therefore cannot test patch at the moment. I'll take look when I regain power64 access.

That is unfortunately not possible because there is no fixed link between the key and the rev cert. Instead they are linked via cryptographic signatures. The pre-generated rev certs are a fail stop measure in the case that the user lost access to the private key and can't create a revocation with a concrete reasons etc.

The changes just follow the existing practice of Ed25519, which does:

You are very welcome, i'll let you know if i found more issues in the future, same goes to libgcrypt.

Switching to assembly for the shifts made a significant speed-up. As Minicloud is seemingly broken (can't open up ssh port) I cannot test on 64-bit big-endian or 32-bit and have thus made it 64le-only.

Changes pushed to master.

To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.

Pushed the patch to master.

It's me who should say "thank you".

Yes, i always build it with PKG_CONFIG_SYSROOT_DIR but never had any issues with it until 1.38 version, your suggestion definitely fixed it. Thank you.

Or one liner patch would be enough:

IIUC, you build libgpg-error with setting PKG_CONFIG_SYSROOT_DIR.
It results errors, because while old gpg-error-config never supports PKG_CONFIG_SYSROOT_DIR, it compares result from old gpg-error-config and gpgrt-config gpg-error.

Please give us full build log here, so that we can investigate what's going on. You can upload log file by the "upload" button in comment edit dialog.

Any news on this?

5 or 10 minutes are not reasonable in this case. Users are expected to attend the key generation. Your idea of having a countdown after, say 30 seconds, makes sense and should be easy to implement in the pinentries.

Thanks for explaining; this may indeed lead to a followup processing error of correct data. However, I don't expect to ever see a fixed length header of 2GiB or more because the sender would have had to buffer all that data in the first place.

Confirm gpg-error-config works... no

• Please report to https://bugs.gnupg.org with gpg-error-config-test.log

Makefile:1667: recipe for target 'gpg-error-config' failed