Conversation
Swift does not have a native tar reader/writer, and we'd really like to avoid linking more (libarchive) libraries to vminitd if we can get away with it. For copying directories into/out of containers tar is fairly nice as it's a simple way to preserve everything you need to be able to reassemble the directory on the receiving end. Due to this, I decided to write a somewhat simple tar reader/writer solely for this purpose. Unfortunately, there's quite a lot of work to get vminitd/ to compile on macOS without the static linux SDK, so it was making unit testing these additions quite a pain, so for now the new work lives in _ContainerizationTar (where the underscore is trying to denote that this is rather experimental..). This change aims to add a simple tar reader and writer with support pax extended headers (for long file names and > 8 GiB files). Because its intended purpose is in a scenario where we own both the creator and ingestor, the reader does NOT handle every case, but it is good at unarchiving the archives the library has made :)
|
I don't think we need a new set of rpcs. Presumably we can reuse the copyIn/copyOut and if you need extra info just add it to the proto message |
|
@simone-panico @dcantah One thing to keep an eye on is when this lands in the swift SDK: swiftlang/swift-docker@ea31a33. At that point we might be able to replace any homegrown archiver we use with libarchive. |
So that means ContainerizationTar is not sure to be merged? |
Hi Simone! I'm not sure when the updated Swift SDK is going to be available. The plumbing for a tar-based implementation will be the same regardless of whether we have a homegrown tar or libarchive, so I'm fine with merging everything we need for The main concern I have is that if we implement tar ourselves, it needs to be secure. |
| } | ||
|
|
||
| /// Extract a tar archive to a destination directory. | ||
| private static func extractTar(reader: TarReader, to destURL: URL) throws { |
There was a problem hiding this comment.
@simone-panico Have a look at https://github.com/apple/containerization/blob/main/Sources/ContainerizationArchive/ArchiveReader.swift#L304. I had to do similar fixes there back in January 😄.
You're skipping entries containing .., but the implementation can currently write through symlinks there's a TOCTOU race between creating the parent directory for a regular file extraction, and writing the regular file.
The tests for exercising safe extraction are at: https://github.com/simone-panico/containerization/blob/main/Tests/ContainerizationArchiveTests/ArchiveReaderTests.swift
|
Dev snapshots are out now: swift sdk install \
https://download.swift.org/swift-6.3-branch/static-sdk/swift-6.3-DEVELOPMENT-SNAPSHOT-2026-02-27-a/swift-6.3-DEVELOPMENT-SNAPSHOT-2026-02-27-a_static-linux-0.1.0.artifactbundle.tar.gz \
--checksum 7dc6f58d1300438ebcf2e998de7c69d8da0ec42102460bd8e7f91c668e8b30c6 |
Nice, I will try to switch out the |
|
@simone-panico Do you mind if we try and handle the Containerization side and you can plumb this through in
There's a lot of solutions to these, but they all have drawbacks to me.. |
Yeah sure, go for it. The main goal in the first place for me was to finally merge the |
3 participants
This pull request introduces functionality to support copying directories between the host and container #543.
See #1190 for more context.