init `cdx:maven` taxonomy with existing properties

[hboutemy]

fixes #68 with existing properties added in cyclonedx-maven-plugin 2.7.7 and 2.7.9 once this is done, we'll add new properties later

[hboutemy]

thanks for the feedback: I improved the taxonomy

I have one question: I named the taxonomy cdx:maven:package to mimic other taxonomies in this repository, but wouldn't it be better named cdx:maven:metadata to match CycloneDX schema element?

[jkowalleck]

re https://github.com/CycloneDX/cyclonedx-property-taxonomy/pull/69#issuecomment-1661578489

The xxx:package:yyy were chosen as the properties describe a package or component. Looking into the details of your taxonomy description, I get the idea that your properties describe build processes or formulation, others describe the BOM generation process itself. You probably want to rename the properties, so it is clear in which domain they shall be used and what they describe.

I am not familiar with maven dependency management, you should gather feedback from your peers :D Here are my 2 cents

• cdx:maven:package:goal -- this is not maven specific but implementation specific for cyclonedx-maven-plugin, i do not have any idea which category this might belong
• cdx:maven:package:reproducible -- is not maven specific. this could be a general cdx:bom:reproducible property. CC @stevespringett @CycloneDX/core-team

I am not familiar with maven dependency management, you should gather feedback from your peers :D

[hboutemy]

The xxx:package:yyy were chosen as the properties describe a package or component.

this way of describing hides if the "package or component" is the output of the build or if it's a dependency (or even a tool)

Looking into the details of your taxonomy description, I get the idea that your properties describe build processes or formulation, others describe the BOM generation process itself.

everything for the moment describes the BOM generation process itself, then it's natural that all go into one single namespace: FYI, here is the current cyclonedx-maven-plugin output gefore mugrating to the official taxonomy that this PR is trying to create https://gist.github.com/hboutemy/e9bed6b890e10450a8410f317e8d6e07

does it describe the package or something else, then how should it be named is my question: I did not try to execute other tools in other technologies to see where they used their xxx:package:yyy taxonomy

cdx:maven:package:reproducible -- is not maven specific. this could be a general cdx:bom:reproducible property.

AFAIK, CycloneDX is inheritently against Reproducible Builds (because it expects the build timestamp to be stored): the feature is currently Maven specific, as it drops the usual timestamp (that has no real meaning in that case)

For now, I prefer keeping that Maven specific: we'll see later if moving to a more common taxonomy makes sense

[stevespringett]

AFAIK, CycloneDX is inheritently against Reproducible Builds (because it expects the build timestamp to be stored)

Timestamp is required per NTIA Minimum Elements. The team is not against reproducible builds, although they do very little to increase assurance, especially with Maven and similar ecosystems. This is being demoed at BlackHat this week. We should likely keep reproducible out of Maven specifically and have it somewhere else thats common.

We should likely change the following:

{
  "name" : "maven.scopes",
  "value" : "compile,provided,runtime,system"
}

to

{
  "name" : "cdx:maven:package:scope",
  "value" : "compile"
}
{
  "name" : "cdx:maven:package:scope",
  "value" : "provided"
}
{
  "name" : "cdx:maven:package:scope",
  "value" : "runtime"
}
{
  "name" : "cdx:maven:package:scope",
  "value" : "system"
}

This would automatically form an array for many parsers and implementations would not have to parse value to separate out the scopes.

[jkowalleck]

We should likely keep reproducible out of Maven specifically and have it somewhere else thats common.

let's have a boolean property cdx:reproducible in https://github.com/CycloneDX/cyclonedx-property-taxonomy/blob/main/cdx.md

--

some other implementations that can generate “reproducible” BOMs, by omitting time- and random-based values, ordering elements, and so on already exist. they just dont add a property to the BOM, yet.

• https://github.com/CycloneDX/cyclonedx-php-composer
• https://github.com/CycloneDX/cyclonedx-webpack-plugin
• https://github.com/CycloneDX/cyclonedx-node-npm

i wonder where this property should be applied, then. I find bom.metadata.properties a good spot, because it exists since CDX1.3

[hboutemy]

yes, bom.metadata.properties is where I store the fact that the BOM is expected to be reproducible

once the cdx:reproducible property will have been registered, I'll update this PR to drop the Maven-specific one

[jkowalleck]

yes, bom.metadata.properties is where I store the fact that the BOM is expected to be reproducible

once the cdx:reproducible property will have been registered, I'll update this PR to drop the Maven-specific one

just opened https://github.com/CycloneDX/cyclonedx-property-taxonomy/pull/70 to request a cdx:reproducible

[jkowalleck]

@hboutemy sorry for my very late reply. what is the status of this PR? should it be merged as is? or do you want to add/change something?

[hboutemy]

time passed, re-reading the discussions it seems the remaining properties from the proposed taxonomy are completely Apache Maven build tool specific, then don't really make any interest to get them shared outside of cyclonedx-maven-plugin i think this PR can be closed now: we extracted the most useful part = cdx:reproducible