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

archive/zip: invalid zip64 extra fields as per strict interpretation of APPNOTE.TXT #23572

Open
ghost opened this issue Jan 26, 2018 · 5 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@ghost
Copy link

ghost commented Jan 26, 2018

What version of Go are you using (go version)?

Looking at git master (currently d85a353 of writer.go)

Description

There seems to be an error in archive/zip/writer.go when creating a zip64 extra field when the local header offset is less than UINT32_MAX (e.g. for the first file in the central directory).

https://github.com/golang/go/blob/master/src/archive/zip/writer.go#L114 writes the 64-bit offset of the local header to the zip64 extra field even if the 32-bit offset written at https://github.com/golang/go/blob/master/src/archive/zip/writer.go#L129 isn't equal to 0xFFFFFFFF.

According to APPNOTE.TXT, this isn't allowed as per:

      The order of the fields in the zip64 extended 
      information record is fixed, but the fields MUST
      only appear if the corresponding Local or Central
      directory record field is set to 0xFFFF or 0xFFFFFFFF.

While Info-ZIP and other implementations may not care about extraneous fields, Microsoft's implementation explodes accordingly at https://referencesource.microsoft.com/#WindowsBase/Base/MS/Internal/IO/Zip/ZipIOExtraFieldZip64Element.cs,120 because it won't expect the field by this logic https://referencesource.microsoft.com/#WindowsBase/Base/MS/Internal/IO/Zip/ZipIOCentralDirectoryFileHeader.cs,92

Proposed solution

Change https://github.com/golang/go/blob/master/src/archive/zip/writer.go#L126 to say:

	if h.isZip64() || h.offset > uint32max {

instead of

	if h.offset > uint32max {

to mimic the logic some lines above that decides when to write the zip64 extra field at all.

This seems to be the minimal change to fix the issue, otherwise the extra field might need to vary in size.

P.S. thanks to archive/zip authors for providing a readable reference

@ghost ghost changed the title Invalid zip64 extra fields as per strict interpretation of APPNOTE.TXT archive/zip: invalid zip64 extra fields as per strict interpretation of APPNOTE.TXT Jan 26, 2018
@bradfitz
Copy link
Contributor

Is this a regression from Go 1.9?

Do you have sample code / test demonstrating the problem, or is this just from reading the code? Please provide a repo to double check there's a problem.

/cc @dsnet

@bradfitz bradfitz added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 26, 2018
@bradfitz bradfitz added this to the Go1.11 milestone Jan 26, 2018
@ghost
Copy link
Author

ghost commented Jan 26, 2018

This is probably not a regression and has always been slightly wrong.

I am only judging from reading the code of archive/zip and MS.Internal.IO.Zip in parallel.
I'm sorry, I'm not quite willing to spend more time on this. This is a heads-up.

@dsnet
Copy link
Member

dsnet commented Jan 26, 2018

Thanks for the heads up, I'll take a look in the Go1.11 cycle.

@dsnet dsnet self-assigned this Jan 26, 2018
@ianlancetaylor
Copy link
Contributor

@dsnet Please update milestone. Thanks.

@dsnet
Copy link
Member

dsnet commented Jun 13, 2018

Possibility of bug, but not a regression. Bumping to Go1.12.

@dsnet dsnet modified the milestones: Go1.11, Go1.12 Jun 13, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Go1.12, Go1.13 Nov 29, 2018
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@andybons andybons modified the milestones: Go1.14, Backlog Oct 9, 2019
@rsc rsc unassigned dsnet Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants