To reproduce this issue I started Kleopatra with an empty GNUPGHOME and imported 10 S/MIME certs at once (which spawns a gpgsm process each) with enabled logging.

Thanks for the hint on the existing OID I already looked into that and planned to use one from the GnuPG arc, But an existing OID is better. I still need to figure useful workflows but something like this will be useful for smartcards..

Good catch. Thanks for that work. I'll apply it to master and 2.2.

Yes, that term is overloaded. The reason in this case is that we once replaced "trusted key" by "valid key". That term "valid" now conflicts with another older use of valid. Using "self-signed" here seems to be more confusing that just removing the (first) "valid".

This is easy to explain: dirmngr receives already escaped data and that is what you see in the log. For proper parsing of the URI the escaping needs to be removed and only before sending the request the required escaping is applied. '@', '<', and '>' do not need to be escaped and thus you see them as they are.

I anyway plan to extend the --quick-gen-key parameters to allow the specification of several subkeys on the command line.

I removed this specialized error message. Thanks for reporting.

While original npth-1.6 can be compiled with newer gcc (>= 5), we'd say please use CFLAGS+=-std=gnu99 with older gcc, as workaround.

I figured out:

• Removing -D_POSIX_C_SOURCE=200112L works both of gcc 4.9 and gcc 5.5 on Solaris 11.3 (even with -std=c99).
• Then, adding -D_XOPEN_SOURCE=500, gcc 4.9 works, but gcc 5.5 failed by another error (Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications)
  • I confirmed gcc 5.5 defaults to -std=gnu99

I think you'll be better off doing this with the simpler --quick-generate-key and --quick-add-key interfaces, rather than hacking on the domain-specific language used by --batch --generate-key.

Thanks for your offer. I have an account for GCC Compiler Farm. I'm trying with gcc211 machine. will back soon.

In case of gcc 4.8 on Solaris, could you please try this patch (instead of configure patch) to see if it works?

It looks like somewhat complicated more. It seems that specifying _POSIX_C_SOURCE=200112L is not good on Solaris with old GCC. Perhaps, it would have no problem with newer gcc (or -std=gnu99 option).

I think this patch should be backported to STABLE-BRANCH-2-2

I think this patch should be backported to STABLE-BRANCH-2-2

I can confirm that this fix repairs the problem on debian's s390x.

I've just pushed e4a158faacd67e15e87183fb48e8bd0cc70f90a8 to branch dkg/fix-T4501 as a proposed fix for this specific problem (it doesn't introduce anything in the test suite, or try to deal with any of the other %b problems).

OK, i think the reason this is happening is that agent_public_key_from_file (in agent/findkey.c) is screwing up a %b format string in gcry_sexp_build_array.

IIUC, -std=c99 won't solve this issue. It is Solaris specific C99 issue.

Ok, the difference appears to be that on these 64-bit big-endian platforms, they're returning a zero-byte string for the associated comment. When this happens, gcry_sexp_canon_len returns 0 because of GPG_ERR_SEXP_ZERO_PREFIX. The same thing happens on x86_64 platforms when confronted with such an s-expression.

rG5b22d2c4008 tested good under Asan.

Thanks for your report.
Let me handle issue by issue.

Thanks for your report.

It looks to me like gcry_sexp_canon_len is returning 0 on these platforms from within a backtrace like this:

I've just pushed 29adca88f5f6425f5311c27bb839718a4956ec3a to the dkg/fix-T4490 branch, which i believe fixes this issue.

This is known and by design, basically it is a legacy X feature. For Wayland, the window manager determines if a window should be blocking, no grab or grab, not anything applications themselves have control over. This came up many times when I was first making the interfaces. You can reference these two comments, but there are many more in between them.

Validity values are also displayed for all user IDs.
[…]

show-uid-validity
       Display  the  calculated  validity of user IDs during key
       listings.  Defaults to yes.

[…]

Trust values are used to indicate ownertrust and validity of  keys  and
user IDs.  They are displayed with letters or strings:

[…]

revoked
       For validity only: the key or the user ID has been revoked.

@werner, why is it the case that if i'm willing to look up a key via WKD on Monday, i should by definition also be willing to send a followup request to that WKD server on Thursday just because the certificate is marked with an expiration?

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, the final --export-secret-key works fine. so the failure appears to be due to the presence of the (comment) clause. (same as in T4501)

I was talking to Thomas Dickey, who maintains Ncurses. Ncurses had a leak and he offered a config option to remove it. Ncurses config responds to --disable-leaks.

In my opinion, it's good if we can offer:

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, everything works fine on s390x. so the failure appears to be due to the (comment), just like in T4490.

fwiw, i've just tried loading the same keyfile that the s390x (64-bit big-endian) implementation choked on into a running gpg-agent on an amd64 machine (64-bit little-endian) and gpg --full-generate-key succeeded with that same key on amd64.

This is particularly bad for users who have manually specified a given keyserver in dirmngr.conf, because even a transient failure in that keyserver will prevent them from any future keyserver requests until dirmngr decides that the "death" has worn off.

further testing suggests that the invalid URI issue is only present for dirmngr's --keyserver option, and gpg's deprecated --keyserver option actually accepts schema-less hostnames.

see also T4467

Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

"valid user-id" means a user id which is properly bound to the key; that is the self-signature checks out.

I keep this open to track the mentioned change for gnupg 2.2

How a digest algorithim is selected for a key signature

No, personal-digest-preferences are not used to select a digest algorithm for key signatures. The only way to use a different digest-algorithm than select by gpg is by using --cert-digest-algo. But take care, you can easily cut into your fingers when using such override options.

WK you command me to put the file scd.log somewhere.
I am trying to do it on the wires set "F103RB" from ARM (GeeNuke)

I have not yet looked at the details but I do not consider one-time allocation a problem. If you want to silence ASAN it is possible to use gpgrt_annotate_leaked_object( foo). Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

• For 2.3 we should ignore all SHA-1 key certifications and warn about SHA-1 binding signatures and offer to migrate them.

How a digest algorithim is selected for a key signature

We update condig.{guess,sub} only when needed. In the past we had cases with regressions on some rare platforms.

It is because you don't have ${prefix}/bin in your PATH.
Please build having /var/tmp/bin in your PATH.

I'm going to bring newest m4/iconv.m4 from original (gettext), which apparently fixed file descriptor leaks.

Thanks for your report.

An FYI... Once we cleared the earlier findings GnuPG tested OK under Asan. GnuPG itself had no findings, and it did not cause any dependent libraries to generate findings.

Thanks for the tests. I just fixed this one and will do replace some code in master, soon.

I often put an extra nul byte at the end of binary data so that accidental printing the data (e.g. in gdb) assures that there is a string terminator. But right, it should not go out to a file.

That type of variadic macro is GCC extension, see https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

This patch tested OK.

Hello again - can I ask about the status? Or should I consider this as a no-fix? Anything I can assist with?