In that case updating a container to a new version would require everyone to change the container ID they are using. This introduces friction that either causes people not to update, or to develop wrappers that do something similar to this.

Granted, this doesn't always apply to packages you build yourself.

Having signed images to allow trust does seem valuable, but easily verifiable images, without the need for crypto, seems like a more fundamental building block upon which more complex processes can be built.

You are right, they are not mutually exclusive, and we are working on both in parallel. We are working on specifying a standardized way to 1) hash a container in its runnable form, and 2) attach arbitrary signatures constructed from that hash. That will allow using your favorite existing tools (eg. gpg) to create arbitrary trust and verification systems. This is part of the OCP project, and will be implemented by RunC which we donated last month. See https://github.com/opencontainers/runc and https://github.com/opencontainers/specs .

As a rule of thumb, end-to-end trust and naming is most useful to developers ("How do I know I'm building on the right dependency, and using the latest and most secure version?"), and low-level hashing is most useful to ops ("How do I enforce a whitelist of containers allowed on my production cluster based on home-made PKI and policies?")

Another distinction is that you can use Notary (and Docker Trusted Content) with any kind of content - for example Compose files, source artifacts, system packages used to build the container, etc.

A bit OT but it would have been automatic if docker used a content-addressable filesystem to store the image content. Unfortunately `docker commit` is nothing like `git commit` as it creates a differential snapshot of the filesystem. It unfortunate because now the user has to be careful not to insert a lot of data between steps in his Dockerfile or they will be shipped with the container even if removed by subsequent tests.