Win32 - export keys

[Hideki Saito]

This seems more of the operating system limitation causing this 
problem.

Windows handles text and binary data differently while on most of 
Unix based systems, it is handled equally.

When exporting ascii texts (with -a) it doesn't matter, but looks 
like Window's doing its own "formatting" on binary files (probably 
it's assuming stdout is text) and that's probably why you would get 
extra returns...

If you decrypt binary files redirection, same problem happens (you'll 
get garbage)

>
>
>Using gnupg win32, I could not create a valid exported key file using 
>redirected
>stdout.  I found that using the --output option, however, worked fine.
>
>In other words:
>
>gpg --export user1 > user1.key    (created a corrupted file)
>gpg -o user1.key --export user1  (created a valid file)
>
>I did further analysis on the corrupted files:
>
>When I tried to import an unarmoured file, I'd get:
>----
>gpg: mpi too large (51968 bits)
>gpg: mpi too large (41167 bits)
>
>gpg: Ohhhh jeeee: mpi crosses packet bordersecmem usage: 0/0 bytes in 0/0 
>blocks
> of pool 0/16384
>
>abnormal program termination
>----
>
>When I tried to import an armoured file I'd get this:
>----
>gpg: no valid OpenPGP data found.
>gpg: Total number processed: 0
>----
>
>By examining the armoured exported keyfiles from both a stdout redirect and a
>--output specified file, I found that the redirected file had an extra 
>carriage
>return at the end of line ( x'0D0D0A') where as the --output file had just
>x'0D0A' end of lines.
>
>Just thought you would like to know.  I tried searching the mailing lists and
>Readme.W32 doc, but couldn't find anything a mention of this.
>

-- 
Hideki Saito mailto:hideki@allcity.net
PGP Fingerprint(0x82957B66): DE6B 1301 CC7F B915 521B  3736 4716 2919 8295 7B66