feature request: verify and/or update

[mhennings]

when you work locally with images it can happen that your local state differs to the remote state.

i see the following causes:

• local build, never pushed, older than remote
• local checksum not valid (local change/ fscorruption, whatever)
• newer remote

for this i would like to have some kind of "verify" or "update" command to get in sync.

i am aware that pull will fetch the newest remote, but it will overwrite local images even if they are newer.

also pull will not verify checksums.

beside this, it would be nice if there was an option to run that will verify before running.

what do you think?

[crosbymichael]

I like the idea. What do you think @vieux @shykes @creack

[creack]

I think it would be difficult. The registry is pretty dumb and does not process the images sent. In order to do this we would need a much smarter registry.
ping @samalba @shin-

[vbatts]

I like this as well, but this also would require either versioning of image names, or some notion of incrementing the image name (perhaps in addition to the date of the image build).

Verifying is separate, but related. I am interested in this being done too.

[thaJeztah]

Would this be possible once layer checksums are implemented? At least that would allow me to check which local images are out of date. Maybe add some system to check which containers are built from an outdated base-image.

[mhennings]

Each layer already has a checksum (if noone removed tarsum recently)

So its not hard to implement. More or less reading the layer into a tar stream and building a tarsum on it.

Problem is though that on some backends the tarsum will probably always complain, because the backend does not handle all attributes / corner cases properly. (which means: aufs would often say its not the same checksum).

[thaJeztah]

Clear, thanks!

Was just today thinking if it would be possible to check which containers would need a rebuild, in case a base-image was updated. I think it is related, not 100% the same as this issue.

[vbatts]

@mhennings The backend graphdriver doesn't matter for the TarSum, only for the container runtime. TarSum are so far consistent regardless of the graphdriver. And TarSum has not been removed, so that is good :-)

As a side-note, in my efforts to clean up the registry code of the daemon, I've got a branch working on comparing freshness of an image. Should have a PR shortly.

[thaJeztah]

@vbatts thanks in advance! I saw some progress on fingerprinting/signing images. Will keep track :)

[LK4D4]

@thaJeztah @tonistiigi Do you think it's possible to do now? Still worth it?

[thaJeztah]

Isn't this what Docker Content Trust basically does? https://docs.docker.com/engine/security/trust/content_trust/

/cc @endophage

[tonistiigi]

At least some of this was addressed with content addressability in v1.10

[LK4D4]

@thaJeztah @tonistiigi let's then close it and if someone interest will open new issue with current concerns.