Move client side image pull logic to engine-api about engine-api HOT 7 OPEN

/cc @docker/core-notary-maintainers

from engine-api.

@ibuildthecloud thank you for the feedback. I'll try to provide some explanation on how trusted pulls work specifically, then let you decide if you still want changes made to the APIs.

First, trusted pulls rely on a previously existing feature, "pull-by-digest". In this flow, engine is provided with the image name and a checksum of the desired version (in place of the normal tag). This is secure vs a typical pull by tag because the user is specifying the exact content they want to retrieve, rather than a name which could be associated with any content (in a pull by tag it's up to the server to resolve the name).

Content trust then leverages pull-by-digest and moves the name resolution from the server, to the docker CLI. The docker CLI retrieves and validates the trust data for the image repository, looks up the provided tag in that trust data, and receives the checksum (sha256) of the image associated with that tag. It is then able to execute a secure pull-by-digest against the engine.

from engine-api.

@ibuildthecloud Ignore the black magic required to do trusted pulls, just parsing a string to ImageID and Tag is not even straight forward.

I noticed this yesterday while looking into the API client library a little more. I filed #137 in response. If you dig down into the example, it basically shows us just giving a ref to the method and have the engine-api sort out the parsing.

This was actually the goal of the reference package, but that effort needs a little more consolidation.

from engine-api.

I'd rather not do this tbh. This package is designed, as much as possible, to only keep logic shared between API client and server. I agree with @stevvooe that we should work on consolidating the reference package.

from engine-api.

@ibuildthecloud I agree that more client logic should live in a reusable library somewhere. Another example is simply running a container, which is also rather convoluted with this library.

@calavera If this package is designed to keep logic shared between API client and server, perhaps we should create another project as the user-facing library for building apps on top of the Docker API? Something akin to docker-py or dockerode, but for Go. WDYT?

from engine-api.

I think it could in some engine-cli project used by docker/docker and designed in a reusable way 😇

from engine-api.

@vdemeester It may also make sense in distribution.

from engine-api.