CycloneDX
Add option to omit all qualifiers from PackageURLs (--short-PURLs)
SBOMs generated with version 2.7.1 contain PackageURLs with classifier type=jar, which complicates the comparison with SBOMs generated by other tools.
Example:
"purl" : "pkg:maven/com.fasterxml.jackson.core/[email protected]?type=jar"
It would be nice if the Maven Plugin offers a configuration option to omit classifiers altogether, similar to the --short-PURLs option of cyclonedx-npm.
purl does not define precise semantic between no qualifier and type=jar qualifier: https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#maven
looking at purl spec for npm, I don't get what a short purl is (or a long one) in that context: https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#npm
can you give examples, please?
I think that the only option when comparing purls is a straight identical string match - doing anything further would require specific knowledge of what each qualifier means. Different tools produce maven (not sure about others) purls that use different qualifiers - I think they are justifiable, but they make life difficult when working across BOMs.
An example of different qualifiers is that this plugin does this: pkg:maven/com.groupgti/[email protected]?type=jar but trivy does this: pkg:maven/com.groupgti/[email protected]?file_path=jars%2Fminimal-2.0.0.jar
I think this is a deficiency in the purl spec - qualifiers should be specced and only used when necessary. I think that for maven there should be no qualifier by default and one should only be added when it isn't the default.
In the mean time that leaves us with the problem that we can't say that those two purls are the same without additional knowledge, which is what I believe @henrikplate would like solved. From my point of view I'd rather have a more specific option: --omit-maven-purl-type-by-default
If you dropped the type/classifier universally you could get clashes between dependencies. Arguably those clashes could be deduped (is it OK to consider pkg:maven/com.groupgti/[email protected]?classifier=sources the same as pkg:maven/com.groupgti/[email protected] ?)
Exactly, and I agree it could make sense to drop qualifiers more selectively, maybe with an option that takes arguments, e.g. --omit-purl-qualifiers=type,foo,bar.
I also agree that the PURL spec does not say anything about short or long PURLs for npm packages. I referenced the --short-PURLs option of cyclonedx-npm just because I imagined they ran into a comparable a use-case (that is to compare/merge/consolidate SBOMs).
Personally, I ran into the problem when comparing SBOMs generated by different tools at different phases of the development lifecycle, you can find the approach and results here.
I'm carefully thinking at the options.
Re-reading the purl spec on maven, its examples set implicitly define that type=jar is the default, which is honestly classical in Java
Then I think that dropping type=jar on purls generated by cyclonedx-maven-plugin makes sense.
On any other type than jar, I'm convinced this will create confusion/conflicts: I still need to have a concrete case of legitimate shortened case
Would that be a good way forward for you?
Yes.
I think you are right that if the type of the dependency isn't jar (or if there is a classifier) then it needs to specified on the PURL.
I think it is reasonable to drop the type for the default packaging jar (which is also mentioned as the default in the Maven documentation). Any other packaging (or classifiers) should be included.
Independent of this default behavior, however, I still wonder whether it makes sense to include an option like --short-PURLs. The result will be ambiguous, and it should be properly communicated/documented, but it could be useful when it comes to merging/consolidating SBOMs from different sources/tools.
This would be just a simple convenience flag, which spares users from dropping the classifiers at later points of such merging processes.