Still trying to pinpoint the bug, but I am afraid I am stuck.

The error of testQuickUID is strange. In the test, it adds a UID and checks number of UIDs (3 + 1 = 4).
It is not reproducible for me (Debian with Qt 5.9.2, NetBSD 7.0.2 with Qt 5.5.1), gnupg 2.2.x from the repo.

FYI this is still unfixed.
I think it'd be valuable to run another round of fuzzing tests, but this should be fixed before, otherwise it'll just be hit all the time and may hide other bugs.

Please see the original file (hello.txt), CFB-encrypted to two passwords (hello.txt.cfb), and AEAD-encrypted (hello.txt.aead).
Passwords used are '1' and '2'.

(automake should flag non-portable Makefile features - after all it is there to avoid gmake features)

Does this patch help? My artificial test confirmed that this does the Right Thing.

Thank you very much! This is working quite well now.

Yes, that is correct.

This is coming along nicely. It might take longer then with Kleopatra if the key is large (as the new resolver does a full keylisting on every start) but that should be OK and we have plans to optimize that anyway.

In my tests this is resolved with the commits mentioned here.

I guess that you are running on 32-bit architecture where the function keybox_get_keyblock uses 32-bit signed size_t for image_off and image_len.

Fixed in rGca138d5bf36a: gpg: Fix reversed messages for --only-sign-text-ids..

Thanks for your report. I'm going to fix the messages.

I believe that all BSD Makefile issues has been fixed (except python-tar-gz distribution thing for maintainer).
Please test again.

I located the problem. It's Makefile portability issue and it is fixed in: rMb5ec21b9baf0: tests: Makefile portability., rMba6e610baa13: tests: More Makefile portability., and rM3224d7f0ea83: tests: Fix previous commit
It was not your final invocation of "make check" (GNU or BSD), but the one before ("make all" by BSD make) which imported keys for tests.
The "export" directive doesn't work on BSD.

That's weird, I can reproduce it with a fresh pull from dev.gnupg.org (I can't clone it because it keeps giving me an error like "no rule to make target audit-events.h) by configuring with CFLAGS set to -fsantize=address -ldl and LDFLAGS set to -lasan. I added the -ldl because of a linking error with symbol dlsym (only when -fsantize=address is present). It more specifically complains about a READ access of size 1 and heap-buffer-overflow on address 0xb30037b0. It also mentions that this address is a wild pointer. The call tree looks as follows:
iobuf_temp_with_content
keybox_get_keyblock
keydb_get_keyblock
do_export_stream
do_export
export_pubkeys
main

I don't think that -R is a good way to implement BCC - it would be better to encrypt it separately. But people may have different ideas on this.

/* Print all commands.  If a help string is available and that
   starts with the command name, print the first line of the
   help string.  */

For SETKEY this is not true. To change this we would need to have an "alias" flag to tell libassuan that setkey is an alias of sigkey. Not sure whether this really makes sense.

Can't replicate this with gcc's address sanitizer. I found a bug in kbxutil, though.
Can you post a bit more info than just line 1275?

We confirmed in a remote session that the Titus Data Classification plugin ( https://www.titus.com/data-classification-product-collection.php#tmc ) interfered with GpgOL.

OK. Then, it may be some bashi-ism in Makefile. I'll investigate with no bash installed.

Ahh, yes you're right, in fact it is. Although after a bit of testing, Arch is both setting XDG_RUNTIME_DIR and respecting the XDG spec, and so is deleting that directory whenever any given user logs out. Given that, I'm not certain how any features of gnupg that expect /run/user/$UID to persist would work.

That is just coincidence, ie. XDG_RUNTIME_DIR must be set to /run/user/$UID on you box.

It's done. The maintainer of the jabber server will try to automate the renewal in the future.

Thanks for this research. Two weeks ago I also did some testing and started to implement a fast track way for simple encryption(for example without signing and filters). But your path to improve iobuf is probably the more general solution.

Rather surprised that it doesn't know about XDG_RUNTIME_DIR, as a stock install of gnupg on Arch will build its sockets in $XDG_RUNTIME_DIR/gnupg by default.

I sent the maintainer of the jabber server a mail.

The --create-socketdir is not not anymore needed because the socket directory is meanwhile always created. We would need to handle the --dry-run in a special way here.

No, I don't have a smartcard. Perhaps it misdetects one?

Another observation: Just opening the file from the explorer is not enough, but once I was on the details of the digital signature, opening works. So for whatever reasons Firefox and Chromium do not trigger the security check.

Observation: When downloading a new version of Firefox, there is another dialog before the UAC comes and the following UAC is fine then. Question: Why does Gpg4win3.exe directly goes to the UAC and firefox.exe triggers a different dialog?