WIP: Adding optional RPM summary to SBOMs #762
Conversation
a-ovchinnikov
requested review from
eskultety and
brunoapimentel
and removed request for
eskultety
| @@ -87,6 +92,8 @@ def to_properties(self) -> list[Property]: | |||
| props.append(Property(name="cachi2:pip:package:binary", value="true")) | |||
| if self.bundler_package_binary: | |||
| props.append(Property(name="cachi2:bundler:package:binary", value="true")) | |||
| if self.add_rpm_summary: | |||
| props.append(Property(name="cachi2:bundler:package:binary", value="true")) | |||
There was a problem hiding this comment.
Won't this property be a bool in the output after the component properties are merged? Also, shouldn't the name of this Property be cachi2:rpm_summary?
There was a problem hiding this comment.
Ouch, you are right, I meant a totally different thing, an actual string property, but apparently got it mixed up with the flag turning this feature on.
| @@ -7,6 +7,7 @@ | |||
| PropertyName = Literal[ | |||
| "cachi2:bundler:package:binary", | |||
| "cachi2:found_by", | |||
| "cachi2:rpm_summary", | |||
There was a problem hiding this comment.
Should we use a custom cachi2 property or perhaps the description field for a CycloneDX Component instead?
There was a problem hiding this comment.
Maybe. I'll need to think about it more. A Property looks the least invasive way of doing this.
There was a problem hiding this comment.
If we decide to go the component.description path, we might be able to map it to SPDX similarly:
https://spdx.github.io/spdx-spec/v2.3/package-information/#718-package-summary-description-field
There was a problem hiding this comment.
FWIW properties can be straightforwardly converted to annotations.
This change adds an option to include RPM summary in a SBOM. TODO: split into multiple commits Signed-off-by: Alexey Ovchinnikov <[email protected]>
a-ovchinnikov
force-pushed
the
rpm_adding_summary
branch
from
660aada to
4f7631b
Compare
| @@ -216,6 +216,7 @@ class RpmPackageInput(_PackageInputBase): | |||
| """Accepted input for a rpm package.""" | |||
|
|
|||
| type: Literal["rpm"] | |||
| add_rpm_summary: bool = False | |||
There was a problem hiding this comment.
what is the reasoning behind making this configurable? On its own the option doesn't IMO make much sense and I'd like to avoid littering the code with semi-random single-purpose tailored SBOM options in the future by setting this precedent. It's a straightforward change, so why don't we make it the default?
There was a problem hiding this comment.
I think the following reasons are for making it optional: it is PM-specific, the original implementation did not have it, it was requested as an enhancement for a very specific use case, it increases SBOM size (which might or might not be of concern). I don't think having a summary around actually improves a SBOM. While this sets a bad(?) precedent the option is limited in scope to one PM (which is essentially a plug-in for handling packages of a specific format). The option addresses a specific need and everyone else is not affected by its addition.
This change adds an option to include RPM summary in a SBOM.
TODO: split into multiple commits
Maintainers will complete the following section
Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:
/ok-to-test(as is the standard for Pipelines as Code)