On Thu, Sep 06, 2007 at 06:55:59AM -0700, paladino wrote: > > Hi, I'm sorry to jump right in with a dumb question, but I've tried doing > some research myself and I have to confess to much of this being way over my > head. > > I work for a University that uses GnuPG to encrypt files to send out to > various vendors. > > We're having a very odd situation right now with one of our files. > > We are sending a file that has a header line that ends with 13 spaces. We > are encrypting the file from the command line, on a unix machine, with > GnuPG. Here's the actual command our guys are using: > /usr/local/bin/gpg -v -r XXXXXXXX -f &filename
Are you sure about that? There is no '-f' option in GPG. > We are then transmitting the file to a vendor who is unencrypting it with > the windows version of PGP. > > When I look at the file here, immediately before it is encrypted, the 13 > white spaces are still there. When I look at the file at the vendor, > immediately after decryption, the 13 spaces are gone. > > I haven't had any luck with getting more information from the vendor about > what kind of options they are using. I do know they are using a windows > version, and the guy says he basically just double clicks on it, types in a > password, and it unencrypts the file. > > Is there anything obvious that could be causing something like this? Which > end is it more likely the problem is at? This is a mini-bug sort of thing, based on historical practice in the OpenPGP community and two different versions of the OpenPGP. Basically, OpenPGP specifies both binary and text transports. Binary is just that - a binary image of the file, with no changes. Text is canonical text, and there are rules for the canonicalization (change line endings to CRLF, etc). When the OpenPGP spec was written, a piece of 'incorrect' language crept in: that whitespace at the end of a line would not be included in canonical text. PGP already worked fine and never changed their code to match the language in the spec. GPG came along later and followed the spec exactly. For various reasons, this mismatch in canonicalization wasn't really a problem in practice, but nevertheless, in the process of writing the updated OpenPGP spec (which is with the RFC editor now, so it'll be out soon), this was resolved. The new canonicalization rule is the historical one: change line endings, and do nothing to trailing whitespace. It is hard for me to give you exact advice on what to do from here without a few piece of information: 1) What version of GPG are you using? (gpg --version) 2) The command line you are using (I'm fairly sure the one above is not correct, as GPG has no '-f' option). David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
