Unable to read image using Docker daemon provider when architecture has variant

[luhring]

I was looking at anchore/grype#831, and it seems like this is ultimately a problem with how Stereoscope is determining "architecture" and "variant" values for a given image, particularly in the code path used for reading images using the DaemonImageProvider.

How to reproduce

With Stereoscope checked out locally, run:

go run ./examples/basic.go docker:ghcr.io/mattmoor/static@sha256:b7dcd21f108cfed6c394aa18240a26c02f904337a962ca0ffe17368de5c65a23

And you'll see:

DEBU[0000] image: source=DockerDaemon location=ghcr.io/mattmoor/static@sha256:b7dcd21f108cfed6c394aa18240a26c02f904337a962ca0ffe17368de5c65a23
panic: could not read image: unable to override metadata option: unknown architecture: arm/v7

...

Analysis

On this line, It looks like when the Docker daemon provider is attaching metadata to the image, it's setting the architecture to i.Architecture, and setting the variant to "". During the problem scenario, i.Architecture is set to arm/v7 — which means the variant ("v7") hasn't been separated out correctly. This causes the error to bubble up out of WithArchitecture because arm/v7 isn't in the known architectures list (but arm is).

So my first takeaway is: I think we shouldn't necessarily use "" as the variant in this code path.

But what's also interesting is that the source of the arm/v7 value is this call into the Docker client library. The return type (ImageInspect) has explicit fields for Architecture and Variant separately, so I'm not sure why it's not separating out the v7 into the variant for us so we don't have to.

Curious for your all's thoughts! This issue ends up being a showstopper for Syft and Grype users with Apple Silicon using Docker Desktop and images with variants. 🙏