password is "abc". I have some comments in the commit logs.

Can you please show the output of these failing tests? I assume you are running on a 64 bit platform.

Hi Werner, thanks.
Looks like our tests against GnuPG are passing now.
Can you please provide the password for this file as well? 'password' doesn't seem to fit.

Here is a file

Could you please try on the command line. (If you don't know how, see: https://www.wikihow.com/Open-the-Command-Prompt-in-Windows )

Hi aheinecke,
I did some tests with 2.0.7-beta10 and still found some issues.
The message I attached as a test case in previous comment is now properly handled, I see no "signature.asc" attachment and message is correctly tagged as trusted sender; this test message was sent from Evolution and I sent it to myself (sorry for not pointing this out before).

Thanks for the test and the example mail. Should also be fixed now.
While testing I also noticed that the sender email address was also not parsed correctly for these kind of mails and added some code to fix that.

GnuPG stores key in a protocol independent manner. This allows to use the same key material for ssh, X.509 and OpenPGP - if you want that. A side effect is that it is possible to use the same key material also for several subkeys. Note that, unless you use --yes, gpg-agent will issue an additional prompt to request confirmation of secret key deletion. It even will show a warning if gpg-agent knows that the key is used for ssh. The thing here is that gpg-agent is picky about accidentely deleting a secret key. In general this is better than the other way.

It's a bug in the OpenPGP card implementation.
I put an entry in Wiki: https://wiki.gnupg.org/SmartCard#Known_Bug.28s.29_of_OpenPGPcard

I found another issue in current master of GnuPG. Probably you already noticed it - when GnuPG AEAD-encrypts input which is a multiple of chunk size, then incorrect chunk number is used in the last block (+1)
The same happens for decryption.
Here is debug output of 128-byte input decryption with 64-byte chunk len:

gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EF
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 00
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EE
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 01
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 ED
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 02
gpg: DBG: eof seen: holdback buffer has the tags.
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EC
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 80

Hi Werner,
Looks like there is a problem on my side, I miscalculated data length (0x240 while it should be 0x280).
Other then this values are the same:

Can you help me and tell me the AD for the last and the final chunk?
My current values are:

I will eventually look at this. However, sometimes the reason for such conditions can be documentation purposes. Thanks for pointing out.

With AEAD we can immediately check whether the correct passphrase is used. With CFB we can't do that and thus the checking is delayed until we can do the bulk encryption using the session key. At that point it is too late to check for other keys - well we could record that all and try again but that would make the code pretty complicate.

Will go into 2.2.6

I just tested version 2.0.7-beta8 x64 and I can confirm the bug is fixed, GpgOL can decrypt messages properly. Messages also appear to be properly signed.

Thank you. With that message I could reproduce the problem and have a fix. I now get to decryption failed / no secret key as it should be.

hm, i think this is the file:

You can find the message attached.
Message has been saved from Outlook 2013.

Thanks for your report and analysis.

On saturday I could observe the problem with a fresh Windows 10 Home edition.

This handles the problem, thanks.

Kleopatra can still be used without UI Server connectivity. But this might point to a bigger issue.

Here is the firefox warning

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'.

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

Yes, that is correct.

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.

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

/* 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.

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.

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.

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.

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.

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.

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.

This is the log output for sending a GPG message to myself:

So I tried this on Outlook 2016 MSO (16.0.4639.1000) 32-Bit

I also think that when calling sign from the --edit-key interactive menu the experience should be a bit different. Instead of listing all the UIDs (even the revoked one) and then warning about the impossibility to sign some of them, it would be better to re-list only the UIDs that are going to be signed. In case --only-sign-text-ids is specified, the non-text UIDs should be stripped from this list too.

I think that it's the kernel problem in NetBSD, where signal to self cannot result EINTR for pselect.
Well, something like rG031e3fa7b9a6: scd: Wake up the select when new USB scan. can be applied, I suppose.
Let's see for configure.ac and HAVE_PSELECT_EINTR.