Platform selection in docker client has unnecessary error

[willmurphyscode]

What happened:

❯ go run examples/basic.go docker:busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387
[0000] DEBUG image: source=DockerDaemon location=busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387
[0000] DEBUG pulling docker image="busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387"
[0000] DEBUG using docker config="/Users/willmurphy/.docker/config.json"
[0000] DEBUG using docker credentials for "index.docker.io/v1/"
panic: unable to use DockerDaemon source: image has unexpected architecture "s390x", which differs from the user specified architecture "arm64"

goroutine 1 [running]:
main.main()
        /Users/willmurphy/work/stereoscope/examples/basic.go:38 +0x60c
exit status 2

This error affects syft:

❯ syft packages docker:busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387           
 ⠹ Pulling image           

2023/06/01 13:52:00 error during command execution: 1 error occurred:
        * failed to construct source from user input "docker:busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387": could not fetch image "busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387": scheme "docker" specified; image retrieval using scheme parsing (busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387) was unsuccessful: unable to use DockerDaemon source: image has unexpected architecture "s390x", which differs from the user specified architecture "arm64"; image retrieval without scheme parsing (docker:busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387) was unsuccessful: unable to determine image source to select platform

What you expected to happen:

Since I specified an exact digest, and didn't pass --platform, I didn't expect a validation error about the user requested platform.

How to reproduce it (as minimally and precisely as possible):

go run examples/basic.go docker:busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387

Anything else we need to know?:

I chose the digest based on running docker manifest inspect busybox:1.31 and choosing the digest of a platform that doesn't match my platform.

The registry provider doesn't have this error: go run examples/basic.go registry:busybox:1.31@sha256:91c15b1ba6f408a648be60f8c047ef79058f26fa640025f374281f31c8704387 works normally.

Environment:

• OS (e.g: cat /etc/os-release or similar):
  M1 macbook pro, Darwin Kernel Version 22.4.0 arm64.

❯ docker version
Client:
 Cloud integration: v1.0.31
 Version:           23.0.5
 API version:       1.42
 Go version:        go1.19.8
 Git commit:        bc4487a
 Built:             Wed Apr 26 16:12:52 2023
 OS/Arch:           darwin/arm64
 Context:           default

Server: Docker Desktop 4.19.0 (106363)
 Engine:
  Version:          23.0.5
  API version:      1.42 (minimum version 1.12)
  Go version:       go1.19.8
  Git commit:       94d3ad6
  Built:            Wed Apr 26 16:17:14 2023
  OS/Arch:          linux/arm64
  Experimental:     true
 containerd:
  Version:          1.6.20
  GitCommit:        2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc:
  Version:          1.1.5
  GitCommit:        v1.1.5-0-gf19387a
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

[willmurphyscode]

Trying to run this down, there's some learnings to capture here:

1. Running something like docker pull myimage:mytage@sha256:somebytes can mean two completely different things: The digest sha256:somebytes can be the digest of a multi-architecture index, in which case the request to docker is to find that version of that multi-architecture index, and choose a platform out of id, and then download those bytes. Or sha256:somebytes can be the digest of a particular built image (a specific manifest), in which case that image is requested. In other words, the digest might uniquely identify a multi-architecture index, or it might uniquely identify an image (by manifest), and you can't tell which by inspecting the string. A digest does not necessarily reference exactly one image.
2. Specifically, you can't tell which without making a network call to the registry to download any multi-arch index the digest may refer to (e.g. by running docker manifest inspect ...)
3. Syft, and therefore stereoscope, should work in situations where they can talk to a docker socket but not make their own network calls, so we can't download the registry to check whether the digest from point 1 pins an index or a particular image manfiest.
4. The docker API, when pulling an image, doesn't let you pull an image and then receive an unambiguous identifier to what was pulled. Hence this code, which pulls an image, and then reuses the image name from the user (e.g. alpine:latest or whatever) to inspect the image. It is difficult to guarantee that these two calls will point to the same image. There is a digest returned in the JSON during pull, but it can just point to the multi-arch index, not a specific image's manifest. Also, if users have enabled "use containerd for pulling and store images" in docker settings, the events that come back from the API call are slightly different, so relying on them is brittle.

That said, I think we can and should revert the platform default selection from #152, and add some additional test cases to guard against regression here.

[willmurphyscode]

An example of this issue affecting users is anchore/sbom-action#419.