Open thitch97 opened 3 months ago
- 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 thesyft
library we use to generate SBoMs only allows one PURL per package declaration. To get around this, I thought it appropriate to create asyft
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
andpostal
).
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.
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 thecargo
,postal
,scribe
, andsbom
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 thesyft
library we use to generate SBoMs only allows one PURL per package declaration. To get around this, I thought it appropriate to create asyft
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
andpostal
).Resolves #557
Checklist