You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can add many files that are each under the 32bit limit but total over 32bits. This means that the central directory record (which is also 32bit) is out of spec as the offset values that point to the individual file offsets are invalid.
Therefore it's quite easy to make USDZ files that are technically corrupt zip files but USD will happily read again because it ignores the corrupt central directory listing..
However, it also means that you can easily corrupt the output file as well in silent ways, that USD will not read again.
I propose the following:
We clarify in the documentation that it must be a Zip32. This will be part of the AOUSD specification language too.
Zipfile.cpp should validate both the local file headers and the central directory record so we don't get invalid values
We revisit zipfile.cpp to support more of the zip spec, starting with Zip64 support.
This is unlikely to be a security issue, but it is a data loss issue.
Steps to Reproduce
Add a ton of files to a USDZ until you're over the 32bit limit.
Check the central directory listing to see if the offsets point to the individual files.
The text was updated successfully, but these errors were encountered:
dgovil
added a commit
to dgovil/USD
that referenced
this issue
Nov 14, 2024
It is a common point of confusion that USDZ files are Zip64 compliant.
In the AOUSD specification, I'll be mentioning that we only support Zip32 and I'd like to do the same for the USDZ spec doc as well.
See PixarAnimationStudios#3424 for more information
Description of Issue
There is an unfortunate confluence of effects around USDZ's zip file.cpp that I would like to raise and suggest some solutions:
This means that you have the following issues:
Therefore it's quite easy to make USDZ files that are technically corrupt zip files but USD will happily read again because it ignores the corrupt central directory listing..
However, it also means that you can easily corrupt the output file as well in silent ways, that USD will not read again.
I propose the following:
This is unlikely to be a security issue, but it is a data loss issue.
Steps to Reproduce
The text was updated successfully, but these errors were encountered: