Standard dep metadata

[thitch97]

Summary

This serves as the initial implementation of RFC 0059, wherein packit adopts the accepted Standardized Dependency Metadata format. As part of this implementation changes were made in the cargo, postal, scribe, and sbom packages to accommodate the new metadata fields. For backwards compatibility, the new fields exist alongside the deprecated fields instead of replacing them entirely.

Unresolved Issues:

• The standardized format defines a PURLs field (i.e. a set of PURLs) instead of just a single PURL for each dependency. This makes sense in theory, but the syft library we use to generate SBoMs only allows one PURL per package declaration. To get around this, I thought it appropriate to create a syft catalog with a package for each unique PURL as opposed to just a single package. However, I have yet to find a suitable method of testing this approach.

• Though the RFC states: "Note: Both the distros and licenses fields are optional, however if they are given then the non-optional components of them must be set.", I'm not sure what an appropriate place is to enforce that rule (perhaps the parsing logic in cargo and postal).

Resolves #557

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[ForestEckhardt]

• The standardized format defines a PURLs field (i.e. a set of PURLs) instead of just a single PURL for each dependency. This makes sense in theory, but the syft library we use to generate SBoMs only allows one PURL per package declaration. To get around this, I thought it appropriate to create a syft catalog with a package for each unique PURL as opposed to just a single package. However, I have yet to find a suitable method of testing this approach.

I think that your idea makes sense unfortunately I am not sure that I have a much better idea when it comes to how to test this.

• Though the RFC states: "Note: Both the distros and licenses fields are optional, however if they are given then the non-optional components of them must be set.", I'm not sure what an appropriate place is to enforce that rule (perhaps the parsing logic in cargo and postal).

I don't think that there needs to be enforcement of this it would just mean that any buildpack.toml that did not conform would not be compliant and therefore there are no guarantees that it will be compatible with the Paketo Buildpacks ecosystem. I think if critical information is missing then the build will fail and if it is not critical then maybe there will be some malformed logging or SBOM generation and I think that is sufficient for me.