Commit Graph

4 Commits

Author SHA1 Message Date
Tianon Gravi eeaf85b4d2 Add support for BASHBREW_BUILDKIT_SBOM_GENERATOR and provenance
Since Docker's image store can't represent these, we round trip them through our self-managed (or external) containerd image store, which also makes pushing more efficient.
2023-03-02 14:40:46 -08:00
Tianon Gravi 449eb48090 Add "path.Clean" and more comments in gitfs's "resolveSymlink" function 2022-12-16 09:09:58 -08:00
Tianon Gravi 99c15f44c2 Fix "gitfs"'s "Mode()" function and transparently follow symlinks 2022-12-15 11:42:13 -08:00
Tianon Gravi 0b7ae64b2f Add "Builder: oci-import" support
In the case of base images (`debian`, `alpine`, `ubuntu`, etc), using a `Dockerfile` as our method of ingestion doesn't really buy us very much.  It made sense at the time it was implemented ("all `Dockerfile`, all the time"), but at this point they're all some variation on `FROM scratch \n ADD foo.tar.xz / \n CMD ["/bin/some-shell"]`, and cannot reasonably be "rebuilt" when their base image changes (which is one of the key functions of the official images) since they _are_ the base images in question.

Functionally, consuming a tarball in this way isn't _that_ much different from consuming a raw tarball that's part of, say, an OCI image layout (https://github.com/opencontainers/image-spec/blob/v1.0.2/image-layout.md) -- it's some tarball plus some metadata about what to do with it.

For less trivial images, there's a significant difference (and I'm not proposing to use this for anything beyond simple one-layer base images), but for a single layer this would be basically identical.

As a more specific use case, the Debian `rootfs.tar.xz` files are currently [100% reproducible](https://github.com/debuerreotype/debuerreotype).  Unfortunately, some of that gets lost when it gets imported into Docker, and thus it takes some additional effort to get from the Docker-generated rootfs back to the original debuerreotype-generated file.

This adds the ability to consume an OCI image directly, to go even further and have a 100% fully reproducible image digest as well, which makes it easier to trace a given published image back to the reproducible source generated by the upstream tooling (especially if a given image is also pushed by the maintainer elsewhere).

Here's an example `oci-debian` file I was using for testing this:

    Maintainers: Foo (@bar)
    GitRepo: https://github.com/tianon/docker-debian-artifacts.git
    GitFetch: refs/heads/oci-arm32v5
    Architectures: arm32v5
    GitCommit: d6ac440e7760b6b16e3d3da6f2b56736b9c10065
    Builder: oci-import
    File: index.json

    Tags: bullseye, bullseye-20221114, 11.5, 11, latest
    Directory: bullseye/oci

    Tags: bullseye-slim, bullseye-20221114-slim, 11.5-slim, 11-slim
    Directory: bullseye/slim/oci
2022-12-15 11:42:10 -08:00