-
Notifications
You must be signed in to change notification settings - Fork 694
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
standardization around compression params #1145
Comments
https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.1 "application/vnd.oci.image.layer.v1.tar+gzip" --> "application/vnd.oci.image.layer.v1.tar+gzip; param1=x; param2=y" etc? |
There is not one standard algorithm for encoding DEFLATE. Even with the same parameters, different gzip implementations will produce different archives. If you want to record exactly how a layer was produced, the place for that would be in something like an SBOM, not in the mediaType. |
This might be another case for pushing uncompressed content in the descriptor, and compressing at the transport level. |
Yup. Also requiring another optional thing (SBOM) for reproducibility? |
Closing this due to the following:
|
For a given source tar, compression params matter even if the same compression algorithm is used. Often tar.gz layers are produced but different tools set buffer size, compression levels etc differently, so the final layer ends up being different although the source tar is the same and consequently the sha256sum.
As a result, reproducibility and deduplication suffers. Either clients use identical tooling end-to-end (which is unrealistic) or the standards evolve to encode this variability in the spec.
The text was updated successfully, but these errors were encountered: