31–40 of 111 posts
Earlier quoted context omitted.
Or: better yet, just use an archive format for archival and a compression layer for compression. Don't use zip at all.
What non-compressing archive format would you suggest? tar doesn't support random access which is a non-starter for many use cases.
Earlier quoted context omitted.
I doubt it still works but things I needed to get through email I would embed in word documents.
Would probably still work. There's just too many formats which makes it very hard for a content blocker to really stop. I pity the programmer that has to decode the 1000 versions of xls to find the binary blob that could be a virus.
Alas, it's more difficult to get excel to accept that it shouldn't delete leading zeros than it is to check a spreadsheet's sus-o-scale.
From a security perspective, and as a programmer, I've never liked ZIP files precisely because there are two mechanisms to identify the contents, the per-file header and the central directory. When you're defining a format, protocol, or w'ever, ideally there should be a single source of truth, a single valid & useable parse, etc; basically, the structure of the data or process should be intrinsically constraining. Th…
The central directory allows zip archives to be split across multiple files on separate media without needing to read them all in for selective extraction. Not particularly useful today but invaluable in the sneakernet era with floppies.
Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.
Earlier quoted context omitted.
The central directory allows zip archives to be split across multiple files on separate media without needing to read them all in for selective extraction. Not particularly useful today but invaluable in the sneakernet era with floppies.
Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.
Glad to see this bit of security theater recognized as such.
Earlier quoted context omitted.
Or: better yet, just use an archive format for archival and a compression layer for compression. Don't use zip at all.
What non-compressing archive format would you suggest? tar doesn't support random access which is a non-starter for many use cases.
From a security perspective, and as a programmer, I've never liked ZIP files precisely because there are two mechanisms to identify the contents, the per-file header and the central directory. When you're defining a format, protocol, or w'ever, ideally there should be a single source of truth, a single valid & useable parse, etc; basically, the structure of the data or process should be intrinsically constraining. Th…
I don't think you understand the reason for the ZIP archive file design. Back in the late 1980s, backup media for consumers was limited to mostly floppy disks, some users had tape/another hard disk. Say you had a variable number of files to compress and write out to a ZIP archive. IF you write out the central directory first, followed by all the individually possibly compressed and/or encrypted files, you'd have to c…
When it comes to user data the natural programmer instinct for "is exactly what I expect or fail" which is typically good design, falls to pragmatism where try your hardest to not lose data, partial results are better then nothing, is desired.
Yeah, or, you know, just outright reject any ZIP file that doesn't start with a file entry, where a forward-scan of the file entries doesn't match the result of the central-directory-based walk.
There is just so much malicious crud coming in via email that you just want to instantly reject anything that doesn't look 'normal', and you definitely don't want to descend into the madness of recursive unpacking, 'cuz that enables another class of well-known attacks.
And no, "but my precious use-case" simply doesn't apply, as you're practically limited to a whole 50MB per attachment anyway. Sure, "this ZIP file is also a PDF is also a PNG is also a NES cartridge which displays its own MD5" (viz https://github.com/angea/pocorgtfo/tree/master/writeups/19) has a place (and should definitely be required study material for anyone writing mail filters!), but business email ain't it.
Earlier quoted context omitted.
What non-compressing archive format would you suggest? tar doesn't support random access which is a non-starter for many use cases.
DAR (Disk ARchiver)[1] looks to be a good alternative. It supports random access, encryption, and individual file compression within the archive. [1] http://dar.linux.free.fr/
Earlier quoted context omitted.
The central directory allows zip archives to be split across multiple files on separate media without needing to read them all in for selective extraction. Not particularly useful today but invaluable in the sneakernet era with floppies.
Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.