Hi,
While trying to open a particular gpub file in Lagrange, I've found an invalid assumption about zip files in the_Foundation, which is what Lagrange appears to use, but since the motivation and issue manifests here I'm raising it here in the first instance...
In archive.c, there is:
if (magic != SIG_LOCAL_FILE_HEADER) {
/* Does not look like a ZIP file. */
return iFalse;
}
However, zip files are not required to start with a magic number. Zip files are identified by their End of Central Directory Record:
https://en.wikipedia.org/wiki/ZIP_(file_format)#End_of_central_directory_record_(EOCD)
This "feature" of the zip format is used to enable, amongst other things, self-extracting zip archives, which are just regular zip archives prepended with executable bytes. If you wanted to see this in operation and test how Lagrange handles such an archive, rather than me sharing an executable, it would probably be safer for you to create one of your own, using the unzipsfx utility (which is packaged with unzip on Ubuntu, for example):
Start with anyzipfile.zip and run:
cat `which unzipsfx` anyzipfile.zip > anyzipfile.executable.zip
chmod +x anyzipfile.executable.zip
The resulting file, when loaded in Lagrange, is detected to be a zip file. It displays:
📁 ZIP Archive
anyzipfile.executable.zip is a compressed archive.
View archive contents
But clicking on that last line does nothing.
You might ask: why should Lagrange care about opening self-extracting zip archives?! This only comes up at all since I've been experimenting with creating self-extracting gempub files (gempub simply being a zip file, of course). I like the idea of offline capsule archives being even more self-contained. There could be other use cases; I'm sure I've seen old textfiles.com-style files that were zip archives with plain text / ANSI-art headers. But the point is, it would be nice for Lagrange to robustly support the zip format.
Hi,
While trying to open a particular gpub file in Lagrange, I've found an invalid assumption about zip files in the_Foundation, which is what Lagrange appears to use, but since the motivation and issue manifests here I'm raising it here in the first instance...
In archive.c, there is:
However, zip files are not required to start with a magic number. Zip files are identified by their End of Central Directory Record:
https://en.wikipedia.org/wiki/ZIP_(file_format)#End_of_central_directory_record_(EOCD)
This "feature" of the zip format is used to enable, amongst other things, self-extracting zip archives, which are just regular zip archives prepended with executable bytes. If you wanted to see this in operation and test how Lagrange handles such an archive, rather than me sharing an executable, it would probably be safer for you to create one of your own, using the
unzipsfxutility (which is packaged withunzipon Ubuntu, for example):Start with anyzipfile.zip and run:
The resulting file, when loaded in Lagrange, is detected to be a zip file. It displays:
But clicking on that last line does nothing.
You might ask: why should Lagrange care about opening self-extracting zip archives?! This only comes up at all since I've been experimenting with creating self-extracting gempub files (gempub simply being a zip file, of course). I like the idea of offline capsule archives being even more self-contained. There could be other use cases; I'm sure I've seen old textfiles.com-style files that were zip archives with plain text / ANSI-art headers. But the point is, it would be nice for Lagrange to robustly support the zip format.