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.

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

.crx #265

Closed
galeksandrp opened this issue Mar 4, 2016 · 1 comment
Closed

.crx #265

galeksandrp opened this issue Mar 4, 2016 · 1 comment

Comments

@galeksandrp
Copy link

I hear that .crx (chrome extensions) are zip files. And 7-zip says they are zip by Info->Properties button. But https://stuk.github.io/jszip/documentation/examples/read-local-file-api.html don't show listing of archive, and JSZip(data).files shows {}. Example of that file is https://www.eff.org/files/https-everywhere-chrome-2016.2.23.crx

@dduponchel
Copy link
Collaborator

A crx file is a crx package header and a zip file appended. A zip file references its own parts with offsets from the start of the file. Here, bytes are added at the beginning, all offsets are false (since the goal here is to sign a zip file, the offsets can't be updated).
While some tools detect the offset and handle it, JSZip don't (yet). We also forgot to check that case so you don't get an error... just an empty file.
I'll work on a fix.

dduponchel added a commit to dduponchel/jszip that referenced this issue Mar 6, 2016
In some cases (crx files for example), data have been prepended but the
offset didn't change: the previous version read 0 file, didn't check it
and stopped.
This version tries harder to recover from a bad offset. If/when we read
0 file, we will throw an error.

Other tools (unzip, 7zip, etc) handle that case, now JSZip too.

Fix Stuk#265.
dduponchel added a commit to dduponchel/jszip that referenced this issue Mar 11, 2016
In some cases (crx files for example), data have been prepended but the
offset didn't change: the previous version read 0 file, didn't check it
and stopped.
This version tries harder to recover from a bad offset. If/when we read
0 file, we will throw an error.

Other tools (unzip, 7zip, etc) handle that case, now JSZip too.

Fix Stuk#265.
dduponchel added a commit to dduponchel/jszip that referenced this issue Mar 21, 2016
In some cases (crx files for example), data have been prepended but the
offset didn't change: the previous version read 0 file, didn't check it
and stopped.
This version tries harder to recover from a bad offset. If/when we read
0 file, we will throw an error.

Other tools (unzip, 7zip, etc) handle that case, now JSZip too.

Fix Stuk#265.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants