jdaugherty commented on code in PR #15614:
URL: https://github.com/apache/grails-core/pull/15614#discussion_r3171696646
##########
build-logic/plugins/src/main/groovy/org/apache/grails/buildsrc/SbomPlugin.groovy:
##########
@@ -384,4 +396,53 @@ class SbomPlugin implements Plugin<Project> {
}
}
}
+
+ /**
+ * Wires this project's own SBOM into the shadow jar produced by the
+ * com.gradleup.shadow plugin.
+ *
+ * Without this, shadow's first-wins merge picks up a META-INF/sbom.json
+ * from one of the bundled transitive jars (typically grails-shell-cli's),
+ * giving the fat jar the wrong serialNumber and metadata.component
+ * (it ends up describing grails-shell-cli rather than the fat jar's own
+ * project). Two fat jars that both bundle grails-shell-cli (e.g.
+ * :grails-cli and :grails-cli-shadow) then end up with byte-identical
+ * META-INF/sbom.json entries and identical urn:uuid serialNumbers,
+ * which violates the CycloneDX 1.6 specification.
+ *
+ * The fix is symmetrical with publishSbomForJarProjects: we exclude any
+ * META-INF/sbom.json that arrives from transitive dependencies during
+ * the shadow merge, then re-introduce this project's own SBOM (whose
+ * serialNumber is project-path-seeded and unique per fix(sbom): mix
+ * projectPath into deterministic UUID seed).
+ *
+ * Uses the broad Task type to avoid a compile-time dependency on
Review Comment:
We had a compile dependency before that was removed as part of the gradle 9
update, this should remain. We're complicated a generic plugin specifically to
work around one project instead of configuring the individual gradle project
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
