feat: improve VSA generation with digest for each subject

[nathanwn]

This pull request improves upon the VSA generation feature in Macaron, by populating each subject with a corresponding SHA256 digest if certain conditions are met. This change helps VSA generation in Macaron become more in line with in-toto attestation specifications. More importantly, this also improves the VSA's quality in uniquely identifying artifacts verified by Macaron.

Specifically, built on top of Macaron's recent feature of taking a provenance file as input, this pull request identifies if the PackageURL provided through the command-line argument --package-url/-purl of macaron analyze identifies an artifact being one of the subjects in the provenance. If such a subject is found, the corresponding SHA256 digest is stored in the Macaron database, which can then be retrieved and populated in Macaron-generated VSAs.

For example, given the following analyze command

macaron analyze \
    --provenance-file ./multiple.intoto.jsonl \
    --package-url pkg:maven/io.micronaut/[email protected]?type=jar

Macaron will check if there is a jar file for the micronaut-router package among the subjects in the provenance file ./multiple.intoto.jsonl.

In this PR, only PackageURL of type maven is supported. Other PackageURL types can be added in future pull requests.

Some other related changes include

• Disabling provenance discovery in the mcn_provenance_available_1 check in case a user-provided provenance is available.
• Making the mcn_provenance_expectation_1 check also validate the user-provided provenance if it is available.

Below is a comprehensive list detailing the changes made in this PR, spanning across a few of commits:

• b3eb53a fix: disable provenance discovery in case a provenance is already available

• 8c49c69 fix: enable provenance expectation validation for user-provided provenances

• 1b82d5e chore: add a table to the database schema to store sha256 digests of provenance subjects

A new table is created to store the SHA256 hash. One option being considered was to add another column to the _component table. However, since this will introduce breaking changes to the current policy library, I decided against it at this time. Another option considered was the ReleaseArtifact and HashDigest table. However, they are now currently storing a different kind of data to what this pull request wants to achieve. Future revision of the database schema may clarify whether we want to unify these tables and how we want an eventual schema to look like.

• f2ed7f7 chore: introduce maven artifact types and utilities

• 12066e3 refactor: improve extraction of subjects being build artifacts from witness provenances

There was an existing utility function for extracting subjects from witness provenance. It was originally created for the Witness provenance check. It has then been modified, taking into account the product attestor to only recognize subjects that are actual artifacts. This utility function is also now used for matching a subject to a given PURL, introduced in the next commit.

• 7fa98d6 chore: match a witness provenance subject against a maven artifact purl

• 1fbe7ec chore: modify vsa generation to populate each subject with a sha256 digest if it exists

[nicallen]

artifact_name seems a bit ambiguous. Is it the filename?

[nathanwn]

It is indeed the filename. Thanks for pointing out.
I have renamed artifact_name to artifact_filename in 263414b.

[tromai]

LGTM. Thanks for the changes.

[nicallen]

Need to update comment.

[nicallen]

Also need to remove non-existent extensions parameter from comment above.

[nathanwn]

Thanks. Fixed in 9e6f98f.

[behnazh-w]

The patterns in all these types seem to be the same, i.e., {artifact_id}-{version}.extension. Do we really need all these to be created as separate patterns?

[nathanwn]

-javadoc.jar and -sources.jar are not file extensions, but I get the question.

This pattern is currently being used in the MavenArtifact.from_artifact_filename class method to construct a regex to extract the artifact id from an artifact filename.

An alternative I see is to change filename_pattern to something like filename_suffix, which will involve also changing the implementation of the MavenArtifact.from_artifact_filename class method. I am not sure if doing this is exactly simplifying by any means while I chose to do it this was initially to explicitly specify the naming convention of Maven artifacts, but I can change the current implementation to this if you think it makes sense. If you have any other suggestions please let me know.