Import and compute composefs' fs-verity in a multi-staged build #34
Comments
|
containers/buildah#5837 would be a huge help here, but we could also do it by scanning the filesystem in a normal bind mount, and hopefully we can get the same result. |
|
I have a working branch for this. The two composefses are equal with one major issue: when we create a composefs from the image via layer tarballs we use the epoch as the mtime for Using the epoch feels slightly terrible but it's better than something essentially chosen at random. |
|
Another option would be to specify that we use the |
|
Or here are three variations on the same theme:
The last option has a certain appeal but it's also the most "destructive" of all the options and it has an additional problem: I'm not sure how well it would play with things like the various icon/mime/etc cache files which are supposed to be newer than the directories that contain them. We'd have to read those specs carefully, and hope that there's not some other spec that we didn't consider which we accidentally break. On balance I like #2. "Most recent mtime in the entire filesystem" probably ends up being a pretty good proxy for "container creation timestamp". |
|
Hmm shouldn't it just be the mtime of the tar entry that contained the root? |
That's exactly the problem. There isn't one. |
|
There's actually an additional issue here: we might reasonably assume that the owner of the root directory is We definitely need solid specs around these things. They impact the determinism of the process of producing the image. |
It think that's the most reasonable one. It should be fast to find out. Another option is to set it to the oldest mtime for the files present in the root directory. Note that we don't want to change any mtime of other files. This has implications for Python bytecode for example: ostreedev/ostree#1469 |
|
I went with "newest file overall". It's also easy to find out. Note that every time we're importing a filesystem we're scanning the entire thing. Keeping this one extra tiny bit of state around ends up not being difficult at all.
I feel like special-casing as little as possible, and I also don't feel like getting into a fight with podman, so |
There is in the fedora-bootc image: But yeah, there isn't one in So let's honor the tar stream if it exists, otherwise fall back. |
Agree complete. I'm about to push a branch, and this is exactly what I wrote in the documentation that I added. |
|
(Whether |
This turned out to be naive. Simply taking the newest mtime from each tar entry is definitely wrong because it doesn't take whiteouts into account (both the whiteout itself, plus the file that it deletes). |
src/fs.rs contains code for writing the in-memory filesystem tree to a directory on disk, so let's add the other direction: converting an on-disk directory to an in-memory filesystem tree. This will let us scan container images from inside containers. This is necessary because we can't get access to the OCI layer tarballs during a container build (even from a later stage in a multi-stage build) but we can bindmount the root filesystem. See containers/buildah#5837 With our recent changes to how we handle metadata on the root directory we should now be producing the same image on the inside and the outside, which gives us a nice way to produce a UKI with a built-in `composefs=` command-line parameter. Add a new 'unified' example. This does the container build as a single `podman build` command with no special arguments. Closes #34
src/fs.rs contains code for writing the in-memory filesystem tree to a directory on disk, so let's add the other direction: converting an on-disk directory to an in-memory filesystem tree. This will let us scan container images from inside containers. This is necessary because we can't get access to the OCI layer tarballs during a container build (even from a later stage in a multi-stage build) but we can bindmount the root filesystem. See containers/buildah#5837 With our recent changes to how we handle metadata on the root directory we should now be producing the same image on the inside and the outside, which gives us a nice way to produce a UKI with a built-in `composefs=` command-line parameter. Add a new 'unified' example. This does the container build as a single `podman build` command with no special arguments. Closes #34
src/fs.rs contains code for writing the in-memory filesystem tree to a directory on disk, so let's add the other direction: converting an on-disk directory to an in-memory filesystem tree. This will let us scan container images from inside containers. This is necessary because we can't get access to the OCI layer tarballs during a container build (even from a later stage in a multi-stage build) but we can bindmount the root filesystem. See containers/buildah#5837 With our recent changes to how we handle metadata on the root directory we should now be producing the same image on the inside and the outside, which gives us a nice way to produce a UKI with a built-in `composefs=` command-line parameter. Add a new 'unified' example. This does the container build as a single `podman build` command with no special arguments. Closes #34 Signed-off-by: Allison Karlitskaya <[email protected]>
src/fs.rs contains code for writing the in-memory filesystem tree to a directory on disk, so let's add the other direction: converting an on-disk directory to an in-memory filesystem tree. This will let us scan container images from inside containers. This is necessary because we can't get access to the OCI layer tarballs during a container build (even from a later stage in a multi-stage build) but we can bindmount the root filesystem. See containers/buildah#5837 With our recent changes to how we handle metadata on the root directory we should now be producing the same image on the inside and the outside, which gives us a nice way to produce a UKI with a built-in `composefs=` command-line parameter. Add a new 'unified' example. This does the container build as a single `podman build` command with no special arguments. Closes #34 Signed-off-by: Allison Karlitskaya <[email protected]>
src/fs.rs contains code for writing the in-memory filesystem tree to a directory on disk, so let's add the other direction: converting an on-disk directory to an in-memory filesystem tree. This will let us scan container images from inside containers. This is necessary because we can't get access to the OCI layer tarballs during a container build (even from a later stage in a multi-stage build) but we can bindmount the root filesystem. See containers/buildah#5837 With our recent changes to how we handle metadata on the root directory we should now be producing the same image on the inside and the outside, which gives us a nice way to produce a UKI with a built-in `composefs=` command-line parameter. Add a new 'unified' example. This does the container build as a single `podman build` command with no special arguments. Closes #34 Signed-off-by: Allison Karlitskaya <[email protected]>
In order to be able to run the entire build process from a multi-staged build via a single Containerfile build, we need cfsctl to read the OCI content using a --mount/--from option like in https://gitlab.com/fedora/bootc/base-images/-/blob/main/Containerfile.
cfsctl would read the entire container archive, generate the composefs dumpfile, pass it to mkcomposefs and finally get the fs-verity of the resulting EROFS.
Then this layer could build the UKI using this fs-verity-hash.
As we need this hash as a label (i.e. outside of the container), we would then store that as a file or output that on stdout at the end and another step in the build process would add the hash as a label (as it's not possible to add labels with values generated from stages right AFAIK).
The text was updated successfully, but these errors were encountered: