Add support for "file" source type in syftjson unmarshaling

[luhring]

This fixes the root cause of anchore/grype#592.

Syft's "syftjson" format had not accounted for the "file" type of Source during unmarshaling. This PR:

• adds "file" as an expected Source type
• creates tests for Source unmarshaling, including a new test case to catch this "file" case

To address the Grype bug, a follow-up PR will be needed in Grype to use a version of Syft that has this fix.

---

Lingering thoughts for the future:

1. It'd be nice to also assert in tests that all possible Source.Type values are being tested, similar to how we test the completeness of the test suite itself in other areas of the code.
2. Using a source of truth like AllSchemes might be the way to go. But those underlying string values don't line up with the string values we use during marshaling (i.e. "FileScheme" != "file"). (Perhaps we could make them line up, if there's not value in creating two different versions of each given value?)
3. An opportunity to add clarity to the code in the future is to disambiguate the term "scheme". In some places we're using it to refer to the enum of {image, directory, and file), and in other places we're using it to refer to the user input text that precedes a colon (e.g. registry:...).

[spiffcs]

Great test and great find! Glad this was such an easy fix.

[spiffcs]

Quick nit: should the indentation here be moved so it's closer to RawManifest and not at the 0 position of the line?

[luhring]

@spiffcs I can try that! The only constraint here worth mentioning is that this is a string literal (encoded as a byte slice), and it has to match the result of unmarshaling the raw input. The way I've tried to indent so far, it causes a test failure, since those inserted tabs are not expected. Do you have ideas on how to get the test to pass and have this be indented to the positiion of RawManifest?

[spiffcs]

No worries on the indentations. I understand that the byte match fails because of those added characters. The only way we could update it is if the fixture was also represented in the test struct which seems way more brittle than what we're doing now.

[luhring]

Okay, sounds good

[spiffcs]

Regarding the follow-up questions:

• +1 for more enums and lining up the terms
• here is a list of all the "schemes" we use. It looks like (image --> docker, docker-archive, ociarchive, etc). Does this hint that we add more specific source types and be more granular than image in our output? (dir --> directory) this shorthand is probably for user convenience more than anything else. I think we can map (dir -> directory) for the sbom output to keep the convenience. Linking the input value with what shows up in the Source field is a good idea for clarifying terms and keeping concepts linked across the code.

docker:yourrepo/yourimage:tag          use images from the Docker daemon
docker-archive:path/to/yourimage.tar   use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar      use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage              read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
dir:path/to/yourproject                read directly from a path on disk (any directory)
file:path/to/yourproject/file          read directly from a path on disk (any single file)
registry:yourrepo/yourimage:tag        pull image directly from a registry (no container runtime required)

[luhring]

+1 for more enums and lining up the terms

❤️

Re: disambiguation of the word "scheme":

My understanding of the code is that there really are two different concepts here (both of which today are referred to as "scheme" in the code).

There is:

1. "how to find the thing to scan" — i.e. what's used in user input, inspired by the URI spec (e.g. oci-dir:)
2. "what thing was scanned" — i.e., was it a file? was it a directory? was it an image (regardless of if we obtained it using Docker, found it on disk as an OCI archive, pulled it directly from an OCI registry, etc.)?

IMHO, item 1 makes sense to be called "scheme", whereas calling item 2 a "scheme" causes me confusion. On top of that, it seems like we also refer to item 2 as the "source type" in some places (e.g. in Source.Type).

In my mind, one relatively low impact but high value solution would to be to adjust the "item 2" uses of "scheme" to be "type" / "source type". This would, for example, change AllSchemes to AllTypes (in the source package).

Does this perspective make sense?