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?

So I can reproduce the problem on a Windows 7 virtual machine with all important updates up to the 5th of February, 2018.

Thank you for the test :-/
So back to the drawing board.

For other failures, I guess that you are connecting your card, aren't you?
Last year, I introduced a change for key selection to prefer existing card key. That may affect tests. Well, tests should have configure not to try to access card.

HAVE_PSELECT_NO_EINTR is introduced for systems which pselect cannot be interrupted.

Version 2.0.7-beta6
Test 1 (without S/MIME support):
encrypted e-mail shown as plain text (-----BEGIN PGP MESSAGE----- ...), can be decrypted via clipboard and GPA.
Sent message shows same plain text as received one.
No encryption icon in Outlook Inbox.

The changes are made as described. Could you please try:

Trying to reproduce this / staring down the log, I think I might have found the problem.

I think the reason for this is not Exchange Online but that I was using two explorer Windows and switched between Mails while the decryption on the slow exchange folder was still running. This triggered an invalidate_ui while the parsing was active and that then triggered a write / unload just like in T3523

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.

Here's patches I used for testing. First is hack for disabing SHA1+RMD160 'old GPG LITERAL+SIG case' and second is 'iobuf_get to iobuf_read' optimization.

What's in daily use for 15 yrs? GPGME? I thought GPGME was new, but in any case it's broken in the cases mentioned in that thread.