Dockerfile: verify the git tags with the hashes

[AkihiroSuda]

- What I did

Verify the tags of containerd*, runc, tini, and rootlesskit with their commit hashes for tolerance to compromise of the tags.

These binaries are depeneded by docker-ce-packaging here: https://github.com/docker/docker-ce-packaging/blob/7e726fa319c261676d06b6ae10c04a3df80e4c48/static/Makefile#L43-L58

- How I did it

Used https://github.com/containerd/nerdctl/blob/v2.0.4/hack/git-checkout-tag-with-hash.sh

- How to verify it

Build Dockerfile and Dockerfile.simple

- Human readable description for the release notes

- A picture of a cute animal (not mandatory but encouraged)

[tianon]

Any idea whether Git upstream has considered something like this in Git itself? It honestly seems a little janky for us to solve this problem with a wrapper script when it's a fundamental issue across the whole ecosystem of Git consumers.

(Also, all these "install" scripts are currently mostly usable outside the "canonical" build environment, and I would definitely prefer they stay that way, so relying on some script added in the Dockerfile is DOA IMO, but perhaps other maintainers feel differently.)

[AkihiroSuda]

Any idea whether Git upstream has considered something like this in Git itself?

idk, but I'm sure I'm not the first one who wanted "git checkout TAG@HASH".
Maybe somebody has already proposed and got rejected in the past?
Not sure how to search it in https://lore.kernel.org/git/ though.

It honestly seems a little janky for us to solve this problem with a wrapper script when it's a fundamental issue across the whole ecosystem of Git consumers.

I guess we should send a proposal to the Git upstream if nobody has really tried it, however, it will take a years until the feature gets deployed to all Git consumers.
So anyway we need a quick workaround that can be adopted right now.

(Also, all these "install" scripts are currently mostly usable outside the "canonical" build environment, and I would definitely prefer they stay that way, so relying on some script added in the Dockerfile is DOA IMO, but perhaps other maintainers feel differently.)

Replaced a wrapper invocation with a shell function.

[AkihiroSuda]

@tonistiigi
Can we merge this as a workaround until merging moby/buildkit#5871 in a buildx release?

[AkihiroSuda]

@tonistiigi @thaJeztah PTAL

[tonistiigi]

Not blocking this, but can you help with moby/buildkit#5871 ?

[AkihiroSuda]

Not blocking this, but can you help with moby/buildkit#5871 ?

Sure, after implementing its dependency moby/buildkit#4905 (PR moby/buildkit#5903)

[AkihiroSuda]

Rebased

[thaJeztah]

Wondering if, for now, we should keep these as separate args, e.g.;

Suggested change

	ARG CONTAINERD_VERSION=v1.7.27@05044ec0a9a75232cad458027ca83437aae3f4da
	ARG CONTAINERD_VERSION=v1.7.27
	ARG CONTAINERD_COMMIT=05044ec0a9a75232cad458027ca83437aae3f4da

Or (including the algorithm);

Suggested change

	ARG CONTAINERD_VERSION=v1.7.27@05044ec0a9a75232cad458027ca83437aae3f4da
	ARG CONTAINERD_VERSION=v1.7.27
	ARG CONTAINERD_COMMIT=sha256:05044ec0a9a75232cad458027ca83437aae3f4da

(could be CONTAINERD_HASH or CONTAINERD_GIT_HASH if we think that's a better name)

[AkihiroSuda]

I don't prefer to inflate the number of the args.
Also, splitting the arg will break existing docker build --build-arg CONTAINERD_VERSION=... scripts

[thaJeztah]

Would indeed be great if something like this would be accepted by Git upstream as a format.

Even with that though, I'm wondering if this approach would technically still be open to TOCTOU-like scenarios, i.e., as a contributor I would have to update the tag and hash, but if a tag would've been compromised by the time I open the PR, I would be codifying the bad hash (how would I be able to detect that I picked the "bad" hash?).

I guess in an ideal world, parties like GitHub and GitLab (but could be someone else) would come with a service similar to Go's sumdb; i.e., tags would not just be immutable through branch-protection rules (or otherwise), but also through a secondary system. When a tag is pushed to a repository, their "sumdb" would register the hash; that registered has would be immutable (so that a forced update to a tag would not update the hash), and when verifying, I could verify if my tag's hash would match the one in that "sumdb" and print a warning / error that the tag.

This is what go modules does when a module version's digest doesn't match what was registered earlier;

GOPRIVATE=github.com/docker/ go mod tidy
verifying github.com/<SOME MODULE>: checksum mismatch
	downloaded: h1:aM6XjGnRAH423IRdlJfG4t8iARHTagqxw4uvcq7rH9Q=
	go.sum:     h1:XhibuNKzaAJo5/2AY/ZXk4Fce21fQyzD7/uTn2WgFsQ=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

in the example above, it was a private module, so the only check was against my local go.sum.

Would that be something that could be done through the "source policy" feature provided by BuildKit? I know you proposed that at the time, and there was something merged, but I never used it;

• RFC: dockerfile: support Dockerfile.sum for pinning sources buildkit#2794
• llbsolver: support pinning sources (same as the "Dockerfile.pin" proposal but agnostic to frontends) buildkit#2943
• dockerfile: support Dockerfile.pin for pinning sources buildkit#2816
• Sourcepolicy buildkit#3332

[AkihiroSuda]

Even with that though, I'm wondering if this approach would technically still be open to TOCTOU-like scenarios, i.e., as a contributor I would have to update the tag and hash, but if a tag would've been compromised by the time I open the PR, I would be codifying the bad hash (how would I be able to detect that I picked the "bad" hash?).

Right. The hash still has to be manually reviewed.

source policy

This could work, but harder to maintain