Page MenuHome GnuPG
Create Task
Maniphest T3194

Export of keys fails (gets mangled) if stdout is redirected to a file on Windows
Closed, InvalidPublic
Actions

Description

Using GnuPG 2.1.21 (libgcrypt 1.7.6) on Windows 10 Pro 64-bit 1703 (OS Build 15063.332), mostly in a Powershell window, I encountered an odd possible issue.

The order in which you add the key export command options, can affect the quality of the exported key.
This can be tested if you import the newly exported key back into the keyring. It will result in an import fail.
So when you type: gpg --import johndoe.gpg, it leads to:

gpg: [don't know]: partial length invalid for packet type 63
gpg: read_block: read error: Invalid packet
gpg: import from '.\johndoe.gpg' failed: Invalid keyring
gpg: Total number processed: 0

The following examples of export commands will result in faulty imports:

gpg --export 'john doe' > johndoe.gpg
gpg --export -a 'john doe' > JohnDoe.asc
gpg --armor --export 'john doe' > johndoe.asc
gpg -a --export 'john doe' > johndoe.asc

However, the following export command results in valid keys to import:

gpg -o johndoe.gpg --export 'john doe'

For now this will be my syntax to export keys in Windows, but I assume this is not how key export is supposed to work. At least it is undocumented.

On my Linux (Debian/Ubuntu-based) VM, gpgp does not seem to suffer from this issue.

Details

Version
Windows, 2.1.21 (libgcrypt 1.7.6)

Event Timeline

Q8WUB created this task.Jun 5 2017, 4:59 PM
• werner added a project: Windows 32.Jun 5 2017, 5:09 PM
• werner added a subscriber: • werner.Jun 5 2017, 5:12 PM

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.

Q8WUB added a comment.Jun 5 2017, 9:21 PM

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

When you guessed, did you mean: gpg -a --export 'john doe' > johndoe.asc ?

Unfortunately, the latter command results in the aforementioned issue when importing back the key it generated.

justus triaged this task as Normal priority.Jun 6 2017, 12:42 PM
justus added a project: gnupg (gpg22).
justus renamed this task from GPG on Windows 10: Order of export-key command affecting exported key quality? to Export of keys fails (gets mangled) if stdout is redirected to a file on Windows.Jun 8 2017, 3:40 PM
• werner raised the priority of this task from Normal to High.Sep 21 2017, 3:44 PM

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

• werner added a comment.Oct 19 2017, 8:52 PM

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?

Please also run a

gpg --version

just to be sure you invoke the right version.

gp_ast added a subscriber: gp_ast.Oct 20 2017, 10:32 AM

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

• werner lowered the priority of this task from High to Low.Oct 20 2017, 11:56 AM

Thanks for testing. Did you try with a powershell?

gp_ast added a comment.Oct 20 2017, 1:24 PM

No, I used the standard Windows command line

• aheinecke added a subscriber: • aheinecke.Nov 28 2017, 4:04 PM

I can reproduce the problem.

Same experience as the original report in PowerShell.

Everything is working fine with the standard windows command line.

• werner added a comment.Nov 28 2017, 5:35 PM

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() ).

• werner closed this task as Invalid.Aug 29 2018, 3:31 PM

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

machsix added a subscriber: machsix.EditedFeb 23 2019, 8:25 AM

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.