Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Decrypting message created on command line causes an error #921

Closed
joshfinnie opened this issue Aug 5, 2014 · 6 comments
Closed

Decrypting message created on command line causes an error #921

joshfinnie opened this issue Aug 5, 2014 · 6 comments

Comments

@joshfinnie
Copy link

Found this interesting bug...

I encrypted a message using the command line, and then try to decrypt it using the web and I get this error:

screen shot 2014-08-05 at 12 36 36 pm

Any idea what might be causing this?
@maxtaco
Copy link
Contributor

maxtaco commented Aug 5, 2014

Thanks for the bug report. I think I've just recently broken this. On it.

@maxtaco
Copy link
Contributor

maxtaco commented Aug 5, 2014

The plot slightly thickens

It's a bug with browserify's zlib implementation and seems to only be an issue with zip (rather than zlib) compression. It works fine with native node, but not with browserify-zlib/pako. Your key is an early keybase key which specifically asks for zip and not zlib, which I think has since been fixed. And gpg from the command line obeys that request (while the JS implementation ignores it). Sooo.. a bunch of different things going on. I'm not going to get to fix it today, hopefully tomorrow. Thanks for the bug report!

@joshfinnie
Copy link
Author

No worries. Thanks for looking into it for me!

maxtaco added a commit to keybase/kbpgp that referenced this issue Aug 6, 2014
@maxtaco
Address keybase/keybase-issues#921.
854df76 
I didn't track it all the way down, but there's an issue with browserify-zlib decrypting
our fake ZIP archives.  When the "flush" is sent with 0 in bytes, it returns a Z_BUF_ERROR,
as if it still wants more data.  I think it's safe to ignore this error, but we should recheck
this assumption.  If we turn out to be wrong, we might need to call into pako directly
as shown above.  Calling into pako directly has problems, though, since it will be included
in the node.js setting which will increase code bloat.
@maxtaco
Copy link
Contributor

maxtaco commented Aug 6, 2014

Fixed for me, want to give it a whirl?

@joshfinnie
Copy link
Author

Looks like the update works for me as well! Thanks for the quick turn-around and the great website.

@maxtaco
Copy link
Contributor

maxtaco commented Aug 6, 2014

You're most welcome. Thanks for the feedback!

@maxtaco maxtaco closed this as completed Aug 6, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@joshfinnie @maxtaco