About Debian: Stable releases are only updated for bug fixes and not for new features. This is an important for almost all production systems. Rolling release distros do not provide a platform which can be used to replicate use cases or problems.

there is only NSIS 2.51 in debian

Cool! Thanks for testing :-)

Thanks for the help,

I can't reproduce this. I sent myself a Mail with capitalized "Andre.Heinecke@intevation.de" while my key only has an identity for "andre.heinecke@intevation.de" and it worked as expected:

Mh, that is strange and indeed a bug if that is so. GpgOL should do some simple normalisation which should prevent exactly such a problem. I'll look into it.

Question has been answered. Closing this.

Thanks for the hints.
The problem for us is that we want to rely on Debian Stable for building Gpg4win and there is only NSIS 2.51 in debian :-/ Maybe we make an exception and package NSIS 3 ourself for debian.

With 3.1 ( https://www.gpg4win.org/version3.1.html ) the problem should be gone. We still have to block outlook when the inline editor is used but that left no artifacts in the past. And if a Mail Window is opened we do not block outlook anymore. We only disable it to show a modal dialog.

At some point we really need to look at better error handling so that such an error would be more visible in the UI.

Thanks for your help / report.

With Gpg4win 3.1.0 ( https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe ) GpgOL no longer uses Kleopatra for signing. So this problem can no longer exist.

I'm lowering the priority to Normal. I've done a lot of GpgOL work and Testing for the upcoming 3.1.0 release and have not seen this problem.

Got confirmation In Bugs.kde.org that this is fixed https://bugs.kde.org/show_bug.cgi?id=389792 as my tests also showed this -> resolved.

Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).

Probably you are right but I don't know Windows internals that much.

I installed 3.1.0-beta and tested all use cases, everything is working properly now.

Should work with the current beta: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe Although the window mangement is still a bit "iffy" but we at least switch back the focus.

Yes sorry, I decided against a release specially for that is it is not super critical, no data loss.

A beta of the next version where this is fixed is available now: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

I've uploaded a beta for the upcoming 3.1.0 Version: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

I wonder if this also works similar in a multi user system:

Fixed. But you need to wait at least 4 seconds even with a 2 seconds ttl. Will go in 2.2.6 in about 3 weeks. Thanks for reporting.

Great.
I'll wait for v3.1.0 then.

Well, if you have access to the user's memory you are lost anyway. Should be fixed, though.

From the log I can see that GpgOL picks up the wrong "Sender" address. It thinks that you sent the mail yourself and then the mail address <> signature does not match. So it is not flagged as Trusted.

Thanks for the report. The broken sentence came from an unterminated hyperlink. I fixed the spelling and the link.

@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.

If possible, please try with this (patched version of scdaemon):

I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:

It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.

@werner there had to be some mix up, as the log snippet is not mine.

This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed

This would be a good solution.

This has also the advantage that we could list the possible curves and let the user select them.

So should we revert this patch and replace it by an explicit command to switch the card to ECC?

It looks like you're having the same issue that I reported: T3761.

Hey, @uwestoehr. It looks like you're having the same issue that I reported: T3761.

Ok, thanks!

Sadly this is a known problem, the workaround is to unselect the mail and then move / modify it through the right click menu.

Hi Andre

Thanks, Werner.
With the latest data everything works fine.
I also a problem with incorrect cipher state resetting if last chunk is 0-size.

C:\Users\XavierFRUTON>gpg --gen-key
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.

Is it possible that your %APPDATA% directory is redirected? Maybe you are running into T3818 I also got "General Error" when trying to generate a key because of that bug.

I found another encoding error which renders the test data uploaded yesterday useless: Here is a bogus AEAD packet:

00000040  d4 84 01 07 01 00 6c 34  7c 37 83 24 2a 11 bc 1c  
00000050  bd 1a 76 da 93 8a
              [start chunk] 32 cd  80 a5 8e db 3a 7d 4a 40  
00000060  c5 0d 82 01 8d 64 7f 65  cd ca 58 d0 e7 db 3b 5e  
00000070  89 d9 1b c8 d9 93 1a 37  3c 0e a5 8f 4b 0d 9f db  
00000080  34 56 c8 f1 e9 b7 f5 0b  d2 53 4f 6c fd f8 e9 16  
00000090  cd a4 ae f6 7f 65
                      [tag] ef 5f  96 af 62 70 f4 30 27 37  
000000a0  68 61 95 0a fb 23
                [extra tag] a6 66  75 7a 47 bb 57 d3 da 5a  
000000b0  4d d1 c2 2f 43 39
                [final tag] cd 22  91 16 1d 92 17 1f f2 cf  
000000c0  0f c9 11 56 d0 a9

Here is the build log from unpatched gpgme https://www.zq1.de/~bernhard/temp/gpgme-build-log-2033.txt
it has some tracebacks from t-callbacks.py

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.