Great :-)
This was a change (fixing file descriptor leaks in iconv.m4) that I needed to do for building fuzzing
https://github.com/google/oss-fuzz/blob/master/projects/gnupg/fuzzgnupg.diff#L178

I patched version 1.13.0 with that commit and installed the patched version on Monday. It appears to have fixed the problem.

Or a better tl;dr; When you send mails without "inline" option everything is fine and standardized. The problem is that the old version of GpgOL that your college uses is too stupid to handle this ;-)

Yes your colleague should or basically needs to upgrade. 2.2.3 is very outdated. There are security issues that were fixed by then etc.

In T4515#125651, @aheinecke wrote:

Hi,

What client does your colleague use so that you have to use PGP/Inline?

That format where the attachment is it's own PGP Encrypted file is very problematic. You basically have mutliple signature and encryption states. An attacker can easily remove or add attachments to the message. The attachment name is leaked. etc. Also see: https://wiki.gnupg.org/PgpPartitioned

Our opinion is that if you really _have_ to use PGP/Inline that you must do so manually using Kleopatra's notepad and Encrypted files.

I am a bit unsure if I just close this as "Wontfix" or move it to Wishlist. I think for now I go with Wishlist but do not expect that feature soon. At least until maybe some really important use case comes up.

Anyway, thanks for your feedback. It is always valuable to know what users would like to have.

Best Regards,
Andre

It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).

Will give you more detailed info about your certificate. For even more details use --dump-chain instead of --list-chain.

Thanks

Applied to master and 2.2. Thanks.

Right, that was missing. Fixed for master and 2.2. Noet that for kill and reload we added this already in 2016.

What client does your colleague use so that you have to use PGP/Inline?

No, that is excessive. If the license blurb will ever be change this can be done but not just because of changing a single letter.

Sorry, I will revert this.

Attacks always get better and thus mitigation based on uncommon jpeg UATs would help only for a short time.
Maybe having a SHA-1 warning in 2.2 is also needed.

Sorry, I have read the short paper wrongly. I misunderstood as if a forged key could be made using existing key.

While I think that building with GCC 4 on Solaris 11/12 is minor issue, requirement of newer POSIX API (on GNU/Linux) would be a bit serious issue.
I pushed my change to fix this.

(hm, i'm pushing apparently successfully to playfair.gnupg.org:/git/libgcrypt.git but it is not showing up here. if you want to fetch this patch, you can also find it on the http-to-https branch at https://gitlab.com/dkg/libgcrypt.git

I would prefer not to fix that. I did some experiments on replacing all the runtime parsed ECC constants by static data. Adding the other constants will then be simple.

I've prepared patch for statically defining mpiutil contants, but I can leave it out and not push to master.

I think you are saying that dirmngr receives the query term as escaped data in the assuan connection from the dirmngr client (typically, gpg, which itself decides how to percent-escape what it feeds into libassuan).

Oh, ah. Ok. I do not read c't no more since about 2005. They are busy people and lead into the right direction.

There is actually a problem with --use-embedded-filename. Given that the option his highly dangerous to use we have not tested this for ages. We will see what you we can about it.

The last lines that the process currently holding wrote in the log:

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.