OS, Compiler, any configure options?

"unblock and set a new PIN" might not be the best description given that we have an "unblock" command to let the user unblock the own PIN using hist reset code. But yes, it is expected that it asks for the Admin PIN.

For support please use one of the community resources (see gpg4win.org) and read the manula (compedium) or one of the hundreds of HOWTO floating in the net.

I do not think that we should support a fork of openssh right now. If we would support it we are bound to maintain that for years - this is not a good idea.

PKA is dead but anyway: What you see is a record from a DNS zone file which has a specific semantic. The 14 for example means that 20 bytes follow.

Than put something into the TXT - it does not matter and is only used to break the wildcard.

Hartmut, please read Andre's mail again - we can't do anything about it if Outlook considers an extra delay of 20ms as too slow.

See the release info over at T5052 which notes the problem. See T5140 for details and update to 2.2.25.

From the specs:

If you configure the subdomain in the DNS this will be used. Thus get a cert for it. The old method should not be used and thus if the openpgpkey subdomain exists gpg concludes that the admin is aware of the new scheme.

Nope, of course SNI is used. You problem is a different one. For example no root certificate, a server configured to allow only TLS 1.3, or a not supported algorithm. Decent versions of GnuPG print some hints if run with -v. BTW, an easier way to test is to use "gpg --locate-external-key" which basically does the same you did.

Sorry, I can' reproduce thus. What kind of key is causing the crash?

Sorry, no. Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break. Even when we added lines starting with the usual comment sign (#) to indicate the offset of the packet, we received quite some bug reports. Thus such chnages will only be done when they are really needed. For all other the rule is still: Use the source, Luke.

There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.

Select your key in the certificate view, click right, select "Backup Secret keys ...", store to a file. Then copy that file in a secure why (USB stick etc) to the new box, import it there.

And I also did a backport to 2.2 :-) See rGa028f24136a062f55408a5fec84c6d31201b2143

We should not do this.

Given that this is limited to macOS I have neither objections for 1.8 nor for master

You better wipe ecc_d_padded or use xtrymalloc_secure.

Put

extern char **environ;

after the the include directives.

Go ahead (but w/o the /*if (keytime*)*/ line ;-)

The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.

The error comes form using READKEY which is processed by gpg-agent. At this time the agent does not yet know the stub key and thus returns ENOENT. At the places before we used "SCD READKEY" which works directly with scdameon and does not need a stub file. We need to review the new(?) way of creating stub files, describe that and then fix this by either making sure tha the stub key is created first or that we use SCD READKEY there too.

Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?

You say that you build using clang but the log shows that you invoke gcc.

No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.

This has been fixed for Unix on 2.2 and 2.3. The command line fix for Windows is a larger thing already tracked by T4398.

We changed the fallback to utf-8 in 2.2 and 2.3 and thus this bug can be closed. On Windows there is still the problem with the command line. However, this is better tracked with T5038 and its related tasks.

Regarding a backport I think that I will eventually backport all app-*c to stable by source copying them. We have a quite stable internal API and thus it is easier to keep at least the card specific code in sync. I did some local work in this directory some time ago.