Repository navigation
Docker Content Trust for docker manifest Command #392
Description
Activity
It would be even better if it exposes the manifest list itself, then we can update DCT's hashes independently of the manifest operations.
Reacted by Riyaz Faizullabhoy@endophage the inspect output from the manifest command is currently the manifest list. Is this helpful?
./build/docker-linux-amd64 manifest inspect clnperez/hello-world { "schemaVersion": 2, "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json", "manifests": [ { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 524, "digest": "sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f", "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 525, "digest": "sha256:d682c60dd1aa745d1822fb92566cbdb4636dafc93294f44896f541337ddcf77a", "platform": { "architecture": "ppc64le", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 525, "digest": "sha256:bcaee2c8a5b6640409d86629c969164beddaf769bf4bf78aa55e4824fe73a275", "platform": { "architecture": "s390x", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 524, "digest": "sha256:9701edc932223a66e49dd6c894a11db8c2cf4eccd1414f1ec105a623bf16b426", "platform": { "architecture": "arm", "os": "linux" } } ] }Probably not. We'd want to actual bytes that were sent to the registry so that we can reliably generate the same hash.
DCT (Notary/TUF) is designed to allow clean upgrade paths for hashing algorithms and we already support both sha256 and sha512. While the registry may currently and for the foreseeable future only use sha256, there's nothing to prevent additional verification being done at download time using additional checksums stored in notary, hence it would be useful at upload time to have the bytes so that we can generate whatever the current set of hashes are.
Additionally, it reduces the number of opportunities for fake/bad hashes to be provided. If for example (and this is just a hypothetical), the checksum was a value returned by the registry and passed all the way back to DCT, it would be desirable to have verification somewhere that the checksum the registry is claiming agrees with the checksum we think it should be claiming based on the data we uploaded. Otherwise a compromised registry can potentially get users to sign bad images. Requiring DCT is passed the same bytes that were uploaded is just such a point of verification.
You mean layer bytes? The layers all have to exist on the registry already to create a manifest list, so none are pushed during any of these steps.
No, just the manifest list bytes. We only aim to sign the top of the tree, in this case the manifest list, and rely on the Merkle-tree properties of checksums all the way down from there.
Reacted by cnorman- added a commit that references this issue
on May 2, 2021 For anyone finding this old issue, the solution to sign a manifest is to use the
notarycommand line.
See: https://github.com/sudo-bot/action-docker-sign#sign-multi-platform-manifests
Ref: sudo-bot/action-docker-sign@ee2b979- closing because we removed
docker trustfrom the CLI; remove support for client-side docker content trust validation #6603
Reacted by William Desportes- closing because we removed
Dependent on #138
We should consider Docker Content Trust implications for
docker manifest-- in particular:DOCKER_CONTENT_TRUST=1 docker manifest push ...should sign the top-level manifest / manifest list hash into NotaryDOCKER_CONTENT_TRUST=1 docker manifest inspect ...should verify signatures for the specified manifest / manifest listIn order to facilitate this we will need
manifest-toolor the underlying library we decide to use (will be decided in #138) to expose the hash and byte size of the manifest list when it pushes one (we must sign in the byte size and hash of the manifest list).We can directly leverage the existing Notary libraries already vendored into docker/cli that are currently used for trusted pushes.
cc @docker/security-team @clnperez @estesp