Add supplier to maven packages #29
Conversation
eygraber
force-pushed
the
maven-package-supplier
branch
2 times, most recently
from
0f1f2ff
to
2559ff9
Compare
|
Can you add a description to this PR? |
|
I'm similarly not clear on the definition. The spdx spec says that:
but I don't know under what condition it might be different from the originating distribution source. Microsoft's NTIA compliant SBOM spec is similarly vague. In any case, this should work out of the box for MavenCentral and Google. Other repositories will have to have their name set correctly by the end user. |
|
Yea so the supplier field is definitely one of those fields that is up to interpretation. In most cases I've seen the PackageSupplier becomes the entity distribution, for example if I were Company XYZ and i shipped software, even though it was built from Open Source, I would be the supplier of the software. There are a couple ways to express this via For what's being discussed, I think Package Download Location may be a more appropriate place to encode this information. |
|
So would a better value for PackageSupplier come from the POM's developers section? |
|
There is a very active discussion in the CISA SBOM tooling workgroup on this topic. Here's a a slide presented at the SBOM-O-Rama last month that may help. For the Maven Plugin, we use the |
|
I pushed an update using the organization name if present. |
|
After testing with my project there are 2 dependencies out of 350 that have an organization name populated. Is there a sane fallback that could be used here? |
|
Does it make sense to fallback to the developer name for PackageSupplier if there is no organization name? |
In my opinion, this does make sense as a fallback. |
|
I pushed an update that uses the first developer with a name as a fallback for PackageSupplier. |
eygraber
force-pushed
the
maven-package-supplier
branch
from
f3db10b
to
272d3fa
Compare
|
For my project it looks like the only POMs that don't specify an Organization or a Developer are Google related (Firebase, Google Play Services, com.google.android.datatransport, androidx, tink, gson, etc...
com.google.firebase:firebase-bom:32.1.1, com.google.firebase:firebase-analytics-ktx:21.3.0, com.google.firebase:firebase-analytics:21.3.0, com.google.android.gms:play-services-measurement:21.3.0, com.google.android.gms:play-services-tasks:18.0.2, com.google.android.gms:play-services-basement:18.1.0, androidx.databinding:viewbinding:8.2.0-alpha11, com.google.android.gms:play-services-ads-identifier:18.0.0, com.google.android.gms:play-services-measurement-base:21.3.0, com.google.android.gms:play-services-measurement-impl:21.3.0, com.google.android.gms:play-services-stats:17.0.2, com.google.android.gms:play-services-measurement-api:21.3.0, com.google.android.gms:play-services-measurement-sdk-api:21.3.0, com.google.firebase:firebase-common:20.3.3, com.google.firebase:firebase-annotations:16.2.0, javax.inject:javax.inject:1, com.google.firebase:firebase-components:17.1.0, com.google.firebase:firebase-installations:17.1.3, com.google.firebase:firebase-installations-interop:17.1.0, com.google.firebase:firebase-measurement-connector:19.0.0, com.google.android.gms:play-services-measurement-sdk:21.3.0, com.google.firebase:firebase-common-ktx:20.3.3, com.google.firebase:firebase-crashlytics-ktx:18.3.7, com.google.firebase:firebase-crashlytics:18.3.7, com.google.firebase:firebase-encoders:17.0.0, com.google.firebase:firebase-encoders-json:18.0.0, com.google.android.datatransport:transport-api:3.0.0, com.google.android.datatransport:transport-runtime:3.1.9, com.google.firebase:firebase-encoders-proto:16.0.0, com.google.android.datatransport:transport-backend-cct:3.1.9, com.google.firebase:firebase-messaging:23.1.2, com.google.firebase:firebase-datatransport:18.1.7, com.google.android.gms:play-services-base:18.2.0, com.google.firebase:firebase-iid-interop:17.1.0, com.google.android.gms:play-services-cloud-messaging:17.0.1, androidx.compose:compose-bom:2023.06.01, com.google.crypto.tink:tink-android:1.8.0, com.google.code.gson:gson:2.8.9, com.android.installreferrer:installreferrer:2.2, com.squareup.okhttp3:okhttp-bom:3.12.10, com.google.android.play:app-update-ktx:2.1.0, com.google.android.play:app-update:2.1.0, com.google.android.play:core-common:2.0.3, com.google.android.play:review-ktx:2.0.1, com.google.android.play:review:2.0.1, com.google.android.gms:play-services-mlkit-barcode-scanning:18.2.0, com.google.android.odml:image:1.0.0-beta1, com.google.mlkit:barcode-scanning-common:17.0.0, com.google.mlkit:vision-common:17.3.0, com.google.mlkit:common:18.7.0, com.google.mlkit:vision-interfaces:16.2.0, com.google.android.play:feature-delivery-ktx:2.1.0, com.google.android.play:feature-delivery:2.1.0
|
src/main/java/org/spdx/sbom/gradle/utils/SpdxDocumentBuilder.java
Outdated
Show resolved
Hide resolved
| ).filter(Optional::isPresent) | ||
| .map(Optional::get) | ||
| .reduce((name, email) -> name + email); | ||
|
|
There was a problem hiding this comment.
Do we want to support the possibility of a developer that has an organization?
I think an example is:
https://repo1.maven.org/maven2/org/jetbrains/annotations/13.0/annotations-13.0.pom
which contains the text:
<developers>
<developer>
<id>JetBrains</id>
<name>JetBrains Team</name>
<organization>JetBrains</organization>
<organizationUrl>http://www.jetbrains.com</organizationUrl>
</developer>
</developers>
which is think is causing this text to appear in the sbom:
“supplier" : "Person: Kotlin Team"
maybe it would be better to output this text instead:
“supplier" : "Organization: JetBrains"
There was a problem hiding this comment.
If a developer is listed as having an organization in the .pom, I wonder whether it's safe to assume that the developer's organization was also the organization that supplied the artifact. My guess would be probably?
There was a problem hiding this comment.
I would think that if the developer specified an organization it would be to differentiate between their organization and the organization that is supplying the artifact.
The use case that comes to mind is a project developed by a foundation, where each developer wants to indicate what organization they're a part of (e.g. Google, Microsoft, etc...) but the supplying organization is the foundation (e.g. Apache).
There was a problem hiding this comment.
I'm actually seeing this pattern in google repos as well, using the developer field with only organization.
|
I wonder if a rebase would trigger the build here. Or if our github actions config is off? |
I think I can actually push on this internally at google to get teams to include it. |
eygraber
force-pushed
the
maven-package-supplier
branch
from
272d3fa
to
1a97720
Compare
|
I rebased and pushed, but that didn't seem to help. |
|
Hrmm, CI appears to be triggered. Can you run |
|
So anyway, lets get this in as is, and address the organization issue in a followup, issue in : #38 |
@loosebazooka you mentioned that you could push internally for including an organization or developer for Google projects that are missing them. Here's the list from my project that are missing them (and also javax.inject, but I don't know who maintains that): |
|
Yeah lemme find owners. |
Specify the PackageSupplier field using the name of the maven repository that the artifact was resolved from in order to adhere to the NTIA required fields.
If no supplier is found, use
Organization: NOASSERTION, as simplyNOASSERTIONdoesn't pass the NTIA validator (the NTIA spec doesn't specify anything about this as far as I can tell).There is currently an issue with retrieving the maven repository's name in Gradle 8.2, which is being discussed in the Gradle Community Slack.