101–110 of 138 posts
Only this week did I discover that yahoo and gmail don't let you send zip attachments. I thought this was a bit silly but now I am agreeing with them!
lovely... its on my "collection" along with the "one square kilometer" pdf : https://www.librarystack.org/one-square-kilometer-for-walter...
I recently created a zip validator and decoder for scanning email attachments, @ronomon/zip. It's not yet open-sourced but it has defenses against excessive compression ratios, mismatching local and central directory headers, ambiguous filenames, directory traversals and symlink traversals, and anything ambiguous that could exploit differences in zip implementations, e.g. some zip implementations decode from the fron…
If I recall my PKZip lore, being able to append an updated file to the end of a zip was considered a feature. That leaves a dead copy of the file earlier in the archive, but saves you having to do the floppy shuffle to update one file. But I don’t recall ever mentioning that fact to someone who already knew it. While you could probably get away with rejecting that file (who still uses that? Some sort of streaming pro…
These "invisible" dead zones can be used for malware stuffing, or to exploit ambiguity across different zip implementations, those that parse forwards (using the local file header as the canonical header) and those that parse backwards (using the central directory header as the canonical header).
For example, a malware author might put an EXE in the first version of a file, and a TXT in the second version of that same file. Those that parse forwards get the EXE. Those that parse backwards get the TXT. Of course, the spec advocates parsing backwards according to the central directory record, but implementations exist that don't do this.
The goal of @ronomon/zip is to scan email attachments at the gateway and reject zip archives that might prove dangerous to more vulnerable zip software running downstream (MS Office, macOS) etc.
Also, as you say, I don't think incrementally updated archives are used much. From what I could see, there were no false positives for rejecting gaps between referenced local files on a small sample of 5000 archives.
I recently created a zip validator and decoder for scanning email attachments, @ronomon/zip. It's not yet open-sourced but it has defenses against excessive compression ratios, mismatching local and central directory headers, ambiguous filenames, directory traversals and symlink traversals, and anything ambiguous that could exploit differences in zip implementations, e.g. some zip implementations decode from the fron…
Earlier quoted context omitted.
I always preferred ARJ; I remember it having both better compression and more useful options than ZIP.
And later came RAR
Earlier quoted context omitted.
1. You put it in a URL marked as "noindex-nofollow". Google will avoid it. You are supposed to only serve the page to identified spam bots anyway. 2. You create an exception so that they never cache the page and don't proxy this exact URL.
> 1. You put it in a URL marked as "noindex-nofollow". Better yet, mark it Disallow in robots.txt - to see "noindex, nofollow", they'd still need to request the URL, running the risk to be served with the bomb. > 2. You create an exception so that they never cache the page and don't proxy this exact URL. They work as reverse proxies on host-basis, I don't think you can exclude a single URL. CF at least will never cac…
Earlier quoted context omitted.
And later came RAR
RAR was great at the time because it offered "solid" archiving like a tar/gz combo. Zip and ARJ both compressed at the file level rather than the archive level.
No. You may be thinking of gzip, a spiritual successor and replacement for the Unix compress/uncompress (and even earlier pack/unpack).
But both ZIP and ARJ, and the earlier ARC, all made multiple-file archives.
Or did you mean that the compression was “carried over” from file to file inside the archive?
Pretty powerful! Lots of breakage with things that touch this file. Simply downloading it in Chrome caused issues, Chrome began extracting it to a temp folder (presumably for some malware scanning?) and quickly started filling the disk. Windows 10 then began doing the same thing for Windows Defender, but some sane limits aborted it after a few seconds.
See, I don’t understand this. Zip is a streamable format. I don’t understand why you would extract the archive before checking the contents? I worked on productizing a code signing tool a while back and I believe the first thing I did after we got it working was change it so nothing touched the disk until after the signature had been validated (in this case the signers had business relationships with each other. This…