Finally found the source of the extra characters: I missed that the decompressed data has the form of a literal data packet. That means one more round of parsing is required to get the final message. After adding those two lines the results of jsxcompressor are pretty good. I tested the following combinations successfully:
- PGP 10.2 (with key that has ZLIB compression as default) - gpg 2.0.18 (default and with --gpg6 set) According to RFC 1950 the first byte of the zlib stream begins with 0x78 (for deflate algorithm). The second byte contains a flag that shows if a 4 byte dictionary follows the header or not. So far I have not seen a message that contains this extra dictionary, so I didn't implement any extra logic to deal with it (if this should be required for DEFLATE to work). For now jsxcompressor looks like a step forward because it fixes the endless loops that I had with zlib compressed messages from gpg. But of course some more testing would be good. I put everything into a new pull request. Also adding jsxcompressor to test/encryption.html. ZIP decompression is untouched. https://github.com/openpgpjs/openpgpjs/pull/47 Thomas 2012/6/25 Sean Colyer <[email protected]> > It's great you're looking into this, the compression is one of the areas > I've been hoping to get back to but have been unable to find the time > recently. It's weird, I generally test against GPG, and I think some of the > settings worked, but I've also hit the endless looping, so not entirely > sure what the issue is. > > FYI: you can use the --compress-algo flag in gpg to try forcing different > algorithms to see which are giving you trouble. It tries to pick them best > on the information in the public key of who it's being sent to otherwise, > so it's helpful to make sure we're focusing on the same one. > > In terms of extra characters that might be an issue with RFC 1950 vs RFC > 1951, they both use DEFLATE, but 1950 has extra header information and the > adler 32 checksum. > > I believe I had looked at the jsxcompressor. I can't remember exactly why > I had chosen not to use it, I think because it integrated a lot of things > they we had already done, like base64. However, if it seems to be a more > reliable or better way to handle compression I have no problem switching > out zip.js > > Hope this helps a bit. > Sean > > >
_______________________________________________ http://openpgpjs.org
