Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #, if available:
Fixes #812
Description of changes:
Before this change, SOCI stored all PAX header records as linux xattrs. PAX header records are a generic key-value pair for TAR files, not specifically linux xattrs. While go does support linux xattrs by prefixing them with SCHILY.xattr, since we didn't parse them back to linux xattrs, they did not behave correctly with SOCI. The most likely way users would experience this is that file capabilities don't work with SOCI.
This change keeps all PAX header records in the ztoc format, but parses out just the linux xattrs without the prefix when creating the filesystem metadata from a ztoc.
Docker, buildkit, buildah/podman, and kaniko all use the go tarHeader.Xattrs to add xattrs which uses the
SCHILY.xattr.
prefix. While there are technically other ways to encode xattrs (e.g.LIBARCHIVE.xattr.
) it doesn't seem common.Testing performed:
make check && make test && make integration
I also re-performed the security capability test from #812 to verify that it works with SOCI now.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.