Default image source does not validate url when interpreting scheme as image

[cjnosal]

What happened:
Syft has a check to retry fetching an image if the docker: or registry: scheme was provided, in case of possible ambiguity and the user wants to scan the docker or registry image from dockerhub (or the environment's default search registry).

If the first interpretation was correct, trying to reinterpret the scheme as image can lead to fetch attempts that can't succeed and misleading log messages.

e.g.

failed to get image descriptor from registry: GET http://myhost:5000/v2/test/app/manifests/sha256:digest: UNAUTHORIZED:
"https://registry:myhost:5000/v2/": dial tcp: lookup registry:myhost: no such host

What you expected to happen:
Syft should validate if interpreting the scheme as image results in a valid image.
e.g. parsing https://registry:myhost:5000/test/app:sha is not a valid image url, so the potential ambiguity can be ruled out, and a second fetch does not need to be attempted.

Steps to reproduce the issue:
Run syft with a registry: scheme specified and an image url that will fail.

[tgerla]

Hi @xtreme-conor-nosal, if we're reading this right, "registry:" needs to be the very first part of the image source. If you put it after the https:// it will indeed be interpreted as a URL. Can you try this scheme instead?

syft registry:myhost:5000/test/app:sha

Can you share the exact test command you are using? We might be misunderstanding the problem here.

[cjnosal]

syft registry:index.docker.io:443/nginx2:latest # deliberate typo


[0000]  WARN scheme "registry" specified, but it coincides with a common image name; re-examining user input "registry:index.docker.io:443/nginx2:latest" without scheme parsing because image retrieval using scheme parsing was unsuccessful: unable to use OciRegistry source: failed to get image descriptor from registry: GET https://index.docker.io:443/v2/nginx2/manifests/latest: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:nginx2 Type:repository]]
[0000] ERROR Failed to parse known_hosts:  from-lib=stereoscope
2023/04/06 18:56:33 error during command execution: 1 error occurred:
	* failed to construct source from user input "registry:index.docker.io:443/nginx2:latest": could not fetch image "index.docker.io:443/nginx2:latest": unable to use OciRegistry source: failed to get image descriptor from registry: Get "https://registry:index.docker.io:443/v2/": dial tcp: lookup registry:index.docker.io: no such host

Looking at the above output:
the unauthorized error is expected (though hidden in larger warning)

unable to use OciRegistry source: failed to get image descriptor from registry: GET https://index.docker.io:443/v2/nginx2/manifests/latest: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:nginx2 Type:repository]]

This is a distraction:

 failed to get image descriptor from registry: Get "https://registry:index.docker.io:443/v2/": dial tcp: lookup registry:index.docker.io: no such host

scheme "registry" specified, but it coincides with a common image name; re-examining user input

If registry: is being reinterpreted as the repository, that implies that index.docker.io:443/nginx2:latest is being reinterpreted as the tag. My understanding is that wouldn't be a valid tag. The re-examination could quietly short circuit, and return a clearer:

[0000] ERROR unable to use OciRegistry source: failed to get image descriptor from registry: GET https://index.docker.io:443/v2/nginx2/manifests/latest: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:nginx2 Type:repository]]

[cjnosal]

Because of the ambiguity between scheme/image, syft doesn't know which of the two errors is "correct". However the presentation is confusing because one is labeled warning and the other error, effectively giving a priority to one by drawing the eye.

Instead of making heuristics more clever, perhaps the better request is to have a non-ambiguous way to provide a scheme?

[wagoodman]

This edge case has always been a problem. We've attempted to account for this, but this code path has gotten more complex over time. I've created #1783 to capture how this could be made better in the future. For now, there may be a way to capture all of the errors from these attempts and make the logging a little more apparent about what went wrong without needing debug level logging enabled.