Good catch. This is due to back porting a change from master. However the extra introduced conditional of
if (sig->version >=4)
will always evaluate to true. It is set a bit above and GnuPG does not handle public key packets with version 3 anymore. So this if can actually be removed. Thus no harm.
Please provide detailed information about the build peoblem. An arbitrary paste from a build does not make up a bug report. If you need support building GnuPG you may want to look for a commercial offer or to ask on a mailing list. From what I see I assume you have an incomplete installation of the supporting libraries.
Frankly, I more or less forgot about these help files. The German version for sure needs an update as weel.
You are lucky. The report came just in time for the 2.2.26 released. Not mentioned over thre but anyway fixed. See T5153
See T5192 for an updated release.
Oh well, sshfs.
Just for reference what OS and file system is this? It looks like some x32 Linux.
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.
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.