Nov 10 2020
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.
Feb 23 2019
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.
Aug 29 2018
There is no way for us to fix. It is a shell issue.
May 2 2018
No longer happens when the good old ldapwrapper is used.
Apr 25 2018
Still happens. There are also "BER" errors that seem random.
Nov 28 2017
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.
Nov 14 2017
Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.
Nov 13 2017
Jochen could you please test this on one of our test VM's again and resolve this then?
Oct 26 2017
Oct 24 2017
I am closing this bug report, as I can't get feedback to fix something.
Oct 20 2017
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.
Oct 19 2017
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?
Sep 21 2017
Raising priority so that we have a chance to review this for the next 2.2 release.
Aug 29 2017
Aug 14 2017
Aug 9 2017
Jul 27 2017
Jul 21 2017
Jul 20 2017
Jul 13 2017
Without more information, we can not act on this.
Jul 12 2017
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.
Jul 3 2017
No I don't recall any such problems, sorry.
Jul 1 2017
Jun 8 2017
Jun 6 2017
Jun 5 2017
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.
May 14 2017
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.
Apr 25 2017
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.
Apr 24 2017
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.