Skip to content
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -140,7 +140,10 @@ class SbomPlugin implements Plugin<Project> {
configureNormalization(project)
ensureLicensesValidated(project)

// sboms are only published to Grails jar files at this time
// sboms are only published to Grails jar files at this time. Projects that produce a fat
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should restore the original comment and remove this verbosity

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 1144b74 - restored the original one-line // sboms are only published to Grails jar files at this time comment. Now that the shadow-jar wiring lives entirely in grails-cli/build.gradle, the verbose explanation in the generic plugin is unnecessary.

// jar via com.gradleup.shadow are responsible for wiring the SBOM into their shadowJar
// task in their own build.gradle (see grails-forge/grails-cli/build.gradle), since fat-jar
// packaging is a project-specific concern and shadow is not a dependency of this plugin.
publishSbomForJarProjects(project, sbomOutputLocation)
}

Expand Down Expand Up @@ -261,10 +264,20 @@ class SbomPlugin implements Plugin<Project> {
}
}

// force the serialNumber to be reproducible by removing it & recalculating
// force the serialNumber to be reproducible by clearing it & recalculating.
// Mix the projectPath into the UUID seed so two modules whose post-processed
// BOM JSON happens to be identical (for example, empty BOM platforms with no
// runtime dependencies, or modules whose metadata.component is filled in
// identically by the CycloneDX plugin) still receive distinct serialNumbers
// as required by the CycloneDX specification. Including projectPath preserves
// reproducibility because the same project path + same content always yields
// the same UUID across rebuilds. This guards against collisions introduced by
// CycloneDX 3.0.0 / Gradle 9 metadata changes.
// See: https://cyclonedx.org/docs/1.6/json/#serialNumber
bom['serialNumber'] = ''
def withOutSerial = JsonOutput.prettyPrint(JsonOutput.toJson(bom))
def uuid = UUID.nameUUIDFromBytes(withOutSerial.getBytes(StandardCharsets.UTF_8.name()))
def withoutSerial = JsonOutput.prettyPrint(JsonOutput.toJson(bom))
def uuidSeed = "${projectPath}\n${withoutSerial}"
def uuid = UUID.nameUUIDFromBytes(uuidSeed.getBytes(StandardCharsets.UTF_8))
bom['serialNumber'] = "urn:uuid:$uuid".toString()

f.setText(JsonOutput.prettyPrint(JsonOutput.toJson(bom)), StandardCharsets.UTF_8.name())
Expand Down
6 changes: 6 additions & 0 deletions grails-forge/grails-cli-shadow/build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,12 @@ shadowJarTask.configure { ShadowJar it ->

it.exclude(
'META-INF/DEPENDENCIES', // until we publish our own SBOM, this won't be correct so exclude
// This module does not apply org.apache.grails.buildsrc.sbom (it's an intermediate build
// artifact, not published). Without this exclude, shadow's first-wins merge picks one of
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we dont need such a long comment:

this is an intermediate build, exclude conflicting filed

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 1144b74 - shortened to a single inline note on the exclude line: 'META-INF/sbom.json', // intermediate build, exclude conflicting files

// the bundled transitive META-INF/sbom.json files (typically grails-shell-cli's),
// producing a fat jar whose SBOM describes the wrong module and shares its serialNumber
// with whichever sibling jar happens to win the merge - violating CycloneDX 1.6.
'META-INF/sbom.json',
'about.html' // restatement of the Eclipse Distribution License - Version 1.0 for jakarta
)
}
30 changes: 30 additions & 0 deletions grails-forge/grails-cli/build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@ import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar
import org.apache.grails.forge.buildlogic.shadowjar.GrailsGroovyExtensionTransformer
import org.apache.grails.forge.buildlogic.shadowjar.GrailsShadowLicenseTransform
import org.apache.grails.forge.buildlogic.shadowjar.GrailsShadowNoticeTransform
import org.cyclonedx.gradle.CyclonedxDirectTask

plugins {
id 'groovy'
Expand Down Expand Up @@ -92,6 +93,16 @@ jarTask.configure { Jar it ->
}
}

// The shadowJar merges multiple jars (including transitive ones from grails-shell-cli, grails-forge-cli,
// etc.) into a single fat jar. Each of those source jars carries its own META-INF/sbom.json published by
// the org.apache.grails.buildsrc.sbom convention plugin, and shadow's first-wins merge would otherwise
// pick a transitive sbom.json (typically grails-shell-cli's) and produce a fat jar whose SBOM describes
// the wrong module. We exclude any incoming META-INF/sbom.json during the merge and then re-introduce
// this project's own SBOM (whose serialNumber is project-path-seeded and unique). This keeps fat-jar
// packaging concerns local to this project rather than leaking shadow knowledge into the generic
// org.apache.grails.buildsrc.sbom plugin. See: https://cyclonedx.org/docs/1.6/json/#serialNumber
TaskProvider<CyclonedxDirectTask> cyclonedxDirectBomTask = tasks.named('cyclonedxDirectBom', CyclonedxDirectTask)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this into the configure since it doesn't appear to be used outside of it

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 1144b74 - moved the cyclonedxDirectBomTask declaration inside the shadowJarTask.configure { ... } block (and inside the skipJavaComponent guard, since that is its only caller).


TaskProvider<Jar> shadowJarTask = tasks.named('shadowJar', ShadowJar)
shadowJarTask.configure { ShadowJar it ->
it.archiveClassifier = 'all'
Expand Down Expand Up @@ -122,8 +133,27 @@ shadowJarTask.configure { ShadowJar it ->
'META-INF/DEPENDENCIES', // until we publish our own SBOM, this won't be correct so exclude
'META-INF/grails-plugin.xml', // we do not start or compile a grails application so these files are not needed (grails-core, url mappings, etc plugins)
'META-INF/grails-plugin.xml.asc', // avoid signing artifacts
// Drop any incoming sbom.json that arrives via transitive jars during the shadow merge;
// re-introduced below from this project's own cyclonedxDirectBom output.
'META-INF/sbom.json',
'about.html' // restatement of the Eclipse Distribution License - Version 1.0 for jakarta
)

// Re-introduce this project's own SBOM after the merge (mirrors the regular jar wiring done by
// the org.apache.grails.buildsrc.sbom plugin). Mirrored only when skipJavaComponent is unset to
// match the convention used elsewhere in the build for projects that opt out of jar publication.
if (!project.findProperty('skipJavaComponent')) {
it.from(cyclonedxDirectBomTask.flatMap { CyclonedxDirectTask t -> t.jsonOutput }) { CopySpec spec ->
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

flatMap is non lazy; isnt the json output the only output? If so just pass the task here

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 1144b74 - swapped to passing the task provider directly:

it.from(cyclonedxDirectBomTask) { CopySpec spec -> spec.into('META-INF'); spec.rename { 'sbom.json' } }

Verified BaseCyclonedxTask declares two @OutputFile @Optional RegularFileProperty outputs (getJsonOutput / getXmlOutput), but SbomPlugin.configureSbomTask calls xmlOutput.unsetConvention() and only ever sets jsonOutput, so at execution time jsonOutput is the only effective output.

(Minor nit on the original phrasing: flatMap on a Provider is lazy in the Provider API sense - it returns a Provider<T> that is only evaluated when needed - but you are right that since there is only one effective output here, the direct task reference is simpler and reads better. Same byte-identical SBOM as before: urn:uuid:beabd2c0-0175-3997-bae5-bb8dd245f97b for :grails-cli regular and -all jar.)

spec.into('META-INF')
spec.rename {
'sbom.json'
}
}
it.manifest { Manifest manifest ->
manifest.attributes('Sbom-Location': 'META-INF/sbom.json')
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this added by the cyclonedx plugin already? Did you check the manifest files? Do we do this anywhere else?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked all three:

  1. Is this added by the cyclonedx plugin already? No. Searched the cyclonedx-gradle-plugin source (3.0.x and master) for Sbom-Location / Sbom-Format and there are zero hits - the plugin does not touch the jar manifest at all.

  2. Did you check the manifest files? Yes. Extracted META-INF/MANIFEST.MF from grails-cli-8.0.0-SNAPSHOT.jar (regular) and -all.jar (fat) after --rerun-tasks:

    • Sbom-Location: META-INF/sbom.json
    • Sbom-Format: CycloneDX

    Without the explicit manifest { ... } block on the shadowJar configure, those entries vanish from the fat jar (shadow merges manifests but does not regenerate the SBOM-pointing entries).

  3. Do we do this anywhere else? Yes - SbomPlugin.publishSbomForJarProjects adds the same two attributes to the regular jar in the same module (lines 389-392). The shadow-jar wiring intentionally mirrors that to keep both jars discoverable by downstream SBOM consumers via the standard manifest header.

Left the manifest block in place; the entries are validated to appear in the output.

manifest.attributes('Sbom-Format': 'CycloneDX')
}
}
}
// Make shadow jar a direct dependency of assemble instead of using deprecated archives configuration
tasks.named('assemble').configure {
Expand Down
Loading