search

Festo-se / cyclonedx-editor-validator

Tool for creating, modifying and validating CycloneDX SBOMs.
https://festo-se.github.io/cyclonedx-editor-validator/
GNU General Public License v3.0
16 stars 4 forks source link

Should `build-public` delete `licensing`? #211

Open mmarseu opened 1 month ago

mmarseu commented 1 month ago

The information in the component.licenses[].license.licensing property is typically only needed internally for license compliance and might even be considered sensitive. After all, nobody should need to know that company A has purchased 3 developer licenses to library X or an enterprise license for framework Y.

What do you think, should build-public delete the licensing field?

italvi commented 1 month ago

Though you are right that such details should not be exposed to the outside, I think other fields within licensing can also be important for e.g. integrator of a product, i.e. licensing.licenseTypes[] or licensing.expiration, so that I know the potential risk of using a product that does not check whether the components are up-to-date. Your opinion on that? Maybe I am missing something but in my opinion build-public should only delete entries per default that are internal according to the specification, e.g. properties within the namespace internal.

mmarseu commented 1 month ago

I follow you logic. It's just that we IMO need some way to delete licensing details (or maybe other information) which is deemed sensitive by the author. Right now, our feature can only delete entire components and properties. I'm not sure how else to do it. Of course, we could always make a feature like that optional with a command-line switch but maybe there is a more generic way to do it that I haven't thought of?

italvi commented 2 weeks ago

Maybe a config-file or as suggested by you command-line switch, where you can state which fields to delete could be a possible idea for build-public? Though then the question would be: Delete this field everywhere or just for some specific components fulfilling criteria XY?

mmarseu commented 2 weeks ago

How about creating our own property taxonomy for cdx-ev like other's have already done? This could allow us to introduce fine-grained "config" options as properties. For my particular use-case that would be fine, because the licensing information is added manually in any case. No reason why I couldn't add such a property at the same time to make build-public delete it.

Though that sort of "officialness" (is that a word?) would IMO require us to be a little more stable. Once we go that way, we shouldn't just go and modify properties willy-nilly as we do features of this tool for now.