Hacker News Reader

Comment by masklinn | Hacker News Reader

While that is true (even if some people really want to stream read zips and will thus trigger tar-style conflicts) that is not what the article is about. The article is really more about software using the "size of central directory" field to find the central directory (a sin Python's standard library apparently commits) versus the "offset of central directory".

A commenter on an other post of that article noted that technically there's no reason for the central directory to be right before the EOCD so seeking backwards from the EOCD by the size of CD is just incorrect. In fact zip was designed such that the central directory could be split across multiple disks (and later files), so it was not possible to guarantee a simple backwards jump from the EOCD to the start of CD.

View on HN

> technically there's no reason for the central directory to be right before the EOCD so seeking backwards from the EOCD by the size of CD is just incorrect

Yes, and in fact APPNOTE.TXT expects implementations to deal with discontiguous CD/EOCD records; it actually mandates that some records appear between them. (It's where ZIP64-specific records go, for example.)

The whole thing seems to stem from a belief by the author of this post that Info-ZIP is the canonical implementation. (This is of course wrong. That would be PKZIP.)

If Info-ZIP is exhibiting the behavior described, then the Info-ZIP implementation is flat out wrong.

(This has happened before. See <https://news.ycombinator.com/item?id=27925393> where the author of that post provides pushback to Mark Adler, receives pushback from Adler in response, and then just stops pushing and defers to Adler's reading. Adler is an expert in his domain, and he's made valuable contributions to free software, but his expertise is in compression, and he's not the authority on the spec or the format; Adler didn't create ZIP or write APPNOTE.TXT—Phil Katz did.)

Author here :)

> a belief by the author of this post that Info-ZIP is the canonical implementation

↑ Where did you get this from?

I don't think nowadays there's such a thing as a canonical implementation — ZIP implementation world is too fragmented and implementations are too widespread.

One more note is that the article isn't about who's right or wrong in terms of interpreting APPNOTE.TXT — this is besides the point. The point there is that a parser discrepancy can cause security issues, and the article documents just another discrepancy found in the real world implementations (and there are A LOT of these with regards to the ZIP format).

> this makes sense—technically both the offset of the Central Directory and the size of the Central Directory are redundant when you consider that the End of Central Directory Record should be, well, at the end of the Central Directory. In a proper ZIP file the following equation should be true: (position_of_EoCDR - size_of_CD == offset_of_CD)

This is a pretty clear statement on normativity.

You also left out an important part of my comment when you quoted it. (The operative word at the front of the sentence is "seems".)

> This is a pretty clear statement on normativity.

I disagree – it's a technical remark on redundancy of fields (this is related to my hypothesis in the article that redundancy in formats is the primary cause of parser discrepancy). It doesn't acknowledge InfoZIP being canonical in any way.

> You also left out an important part of my comment when you quoted it. (The operative word at the front of the sentence is "seems".)

Fair, though my point still stands.

Reply on news.ycombinator.com