clarify maven-central as storage, not maven #24
Conversation
hboutemy
force-pushed
the
maven-central
branch
from
271d735 to
b043967
Compare
scripts/sbom-locations.json
Outdated
| @@ -1,83 +1,83 @@ | |||
| { | |||
| "arrow": { | |||
| "type": "maven" | |||
| "type": "maven-central" | |||
| @@ -146,6 +146,6 @@ def is_sbom(name): | |||
| if sboms: | |||
| sbom = sboms[0] | |||
| url = f"{project.url()}/{lastVersion}/{sbom}" | |||
| cache = f'{pmc}/maven/{project.group_id}/{project.artifact_id}/{lastVersion}/{sbom}' | |||
| cache = f'{pmc}/maven-central/{project.group_id}/{project.artifact_id}/{lastVersion}/{sbom}' | |||
There was a problem hiding this comment.
I think we should keep maven here: I modeled the sboms directory structure after https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst
There was a problem hiding this comment.
I understand: it depends on the meaning we want to give to this
IMHO, purl type of some components is not the best value: for example, Airflow has pypi AND npm, and in the future, mixing multiple purl types will happen more and more (imagine Docker images)
that's why I changed in fact the meaning to "location where the initial storage has been done"
but I confirm that later, I want to have a human description of SBOMs, to let users know how many components are described, split by type of components: people don't read their SBOMs sufficiently IMHO, even on high-level aspects
There was a problem hiding this comment.
(very useful discussion: yes, this study opens key topics of interest)
There was a problem hiding this comment.
9bd0d41 for simpler configuration
There was a problem hiding this comment.
I think it is more meaningful to use the "identification of the artifact" rather than the "location where the initial storage has been done" - after all, an SBOM describes an artifact, so we should have some way to refer to those. I don't think that prevents creating human description of SBOMs, which I agree is also useful.
There was a problem hiding this comment.
I think it is more meaningful to use the "identification of the artifact" rather than the "location where the initial storage has been done"
I agree to the idea
the reality is that Airflow content is listed under a pypi directory, but SBOMs describe either npm or application (see metadata https://github.com/apache/security-site/blob/sboms/sboms/airflow/airflow-2.10.2.md )
given there are multiple artifacts, it's not so easy to say what artifacts are described: the only clear fact is "where did we get these SBOMs from" (aka. "where did the project publish its SBOMs?"), and when writing dlcdn and website in additon to maven-central, I was even myself surprised about the values I got: clarifying where projects publish their SBOMs is more valuable than I thought
I don't think that prevents creating human description of SBOMs, which I agree is also useful.
yes, thanks for merging #25 , this is a true discovery to me to see what other projects did
There was a problem hiding this comment.
I think it is more meaningful to use the "identification of the artifact" rather than the "location where the initial storage has been done"
I agree to the idea
the reality is that Airflow content is listed under apypidirectory, but SBOMs describe eithernpmorapplication(see metadata https://github.com/apache/security-site/blob/sboms/sboms/airflow/airflow-2.10.2.md )given there are multiple artifacts, it's not so easy to say what artifacts are described
Sure - but then I think we should fix that
the only clear fact is "where did we get these SBOMs from" (aka. "where did the project publish its SBOMs?"), and when writing
dlcdnandwebsitein additon tomaven-central, I was even myself surprised about the values I got: clarifying where projects publish their SBOMs is more valuable than I thought
Yeah, I think we should probably still do that, perhaps in scripts/sbom-locations.json or something that's to evolve from that.
There was a problem hiding this comment.
@potiuk can you clarify what artifacts the Airflow SBOMs describe exactly? Indeed my assumption of 'pypi' may have been overly simplistic, but can you confirm if the Purls in the metadata are correct? npm seems strange for Airflow (and indeed https://www.npmjs.com/package/apache-airflow does not exist), and application isn't even listed in https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst at all?
| print(f"fetching {pmc} SBOMs from Maven Central") | ||
| status = os.system(f"python3 scripts/collect-maven-sboms.py {pmc}") | ||
| status = os.system(f"python3 scripts/collect-sboms-from-maven-central.py {pmc}") |
There was a problem hiding this comment.
#36 created with this change
avoids confusion between Maven TLP vs Maven build tool vs Maven Central storage discovered in #23
notice that I was not able to run Python scripts (missing a
requirements.txtfile I suppose, I'm not a Python expert), then my updates are quite theoretical: please check it fully works before merging, I may have missed some impact