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 On Mon, Jun 25, 2012 at 5:46 AM, Thomas Oberndörfer <[email protected]>wrote: > > Hi Sean, > > thanks for merging the pull request in. > > I've created now a new one to combine zip.js and inflate.js into one file: > https://github.com/openpgpjs/openpgpjs/pull/46 > This should enable zlib decompression also in the combined and minified > version. > > Anther issue I'm currently facing is an endless loop in the inflate method > of zip.js when trying > to decompress zlib messages from GPG. This does not occur with messages > from PGP Desktop. > > I tried integrating http://jsxgraph.uni-bayreuth.de/wp/jsxcompressor/ as > an alternative to zip.js > Basically I followed the same way as you with zip.js: jsxcompressor > supports from my understanding > only gzip and zip, so I reused only the inflate method and it looks like > there is also no support for Alder32. > > Current status: could decompress messages from PGP Desktop correctly, no > endless loop for GPG messages > but the decompressed message is spoiled with some useless characters at > the beginning. > My guess is that GPG adds some extra data to the message body that needs > to be filtered out before handing it > over to the inflate method. Then probably zip.js would also work. > > Will investigate here further. > > Best regards, > Thomas > > > > > 2012/6/21 Sean Colyer <[email protected]> > >> Ah, yes, we do have a dependency there. That code as you might note from >> the header is taken from this project: >> https://github.com/gildas-lormeau/zip.js >> >> I've modified the zip.js file by basically stripping out all of the >> things we're not using (everything except decompression) just so that I >> have it configured in the same style as the original project. We could >> presumably merge these into one file at no expense. >> >> In my testing I haven't been using the minified version of the file, and >> I might be the only one currently using the zip decompression (not sure). I >> use it in my gmail chrome extension: >> https://github.com/seancolyer/gmail-crypt. In my extension I just use >> the combined but not minified file. My point here is that it's likely that >> zip decompression had been broken in the .min file for as long as it's been >> in the project. >> >> If you want to look into combining these, feel free. If not, I'll try to >> when I get some time but I've been pretty swamped lately. >> >> Unless you still believe the commits in your pull request have caused >> this issue, I'll go ahead and merge your current pull request in. >> >> Sean >> >> > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
