Since codesigning for all dlls was added this is fully resolved.

It's fixed in master by T3465: --pinentry-mode loopback with --delete-secret-keys, with new confirmation interaction.
For 2.2, you can use --batch and --yes, see T4667: "gpg: deleting secret key failed: No pinentry" when in --batch mode with --pinentry=loopback.

This is caused by the encoding of file in windows. If we directly redirect the stdout to file, windows encodes the file as CRLF+UCSE LE BOM but linux encodes it as LF+UTF-8. To make the file work, I just need to run dos2unix to convert the encoding. Hope it help someone having similar issue.

There is no way for us to fix. It is a shell issue.

No longer happens when the good old ldapwrapper is used.

Still happens. There are also "BER" errors that seem random.

IIRC, I red some hints on using a powershell module to switch the output to binary. I tries to find that mode, or weel its source or scrip) but to no success. It seems to be a common problem with powershell because it is not a real shell as we are used to (where many commands have a /b switch but that switching could also be done using setmode() ).

I can reproduce the problem.

Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

Jochen could you please test this on one of our test VM's again and resolve this then?

I am closing this bug report, as I can't get feedback to fix something.

gniibe: Can you check the status?

No, I used the standard Windows command line

Thanks for testing. Did you try with a powershell?

Tried this on Windows 8.1 (x64) with GnuPG 2.2.1 (libgcrypt 1.8.1) and was not able to reproduce it.

I tried to replicate this but failed. Well, I am on Vista and standard cmd.exe. Can you please try your tests again on a standard cmd.exe shell?

Raising priority so that we have a chance to review this for the next 2.2 release.

Without more information, we can not act on this.

Given that 2.0 reaches EOL in 6 months and the bug has been here for ages, I won't backport it to 2.0 anymore.

No I don't recall any such problems, sorry.

@werner The backport to 2.0 didn't happen, I think. Is this still relevant. @justus Do you recall any more problems in the tests?

Indeed, the difference seems to be the --output versus the stdout to a file.

The difference is the use of the --output option versus redirecting stdout to a file. A first guess would be that setmode (O_BINARY) has not been done, but in that case the -a exports would still work.

Found the problem and fixed it. The Problem is described in the commit. Basically glib always assumed it gets UTF-8 Encoded filenames even if they were provided in system locale through double click / open with / command line / drag & drop.

GpgEX is now also compiled with ASLR + DEP. I still have to check some other binaries of Gpg4win before I close this task but I no longer see it as blocking a 3.0 release where I wanted to have this included.

Talked to Werner about this. He still has concerns that this is wrong because an application should not do globbing itself and only changing this in gpg.exe is inconsistent. It also might be a security problem as most users won't use the double dash to seperate arguments from filenames.

Added this to 3.0 because I don't want to release any known crashes.

I just commited the fix I had in gpg4win 2e71bf3. I don't see how this is objectionable as it changes the behavior back to what we had before we switched to building on jessie and is a minor ifdef.