On 2025-11-15, Jaikiran Pai wrote: > On 11/11/25 11:09 am, Stefan Bodewig wrote:
>> the main problem seems to be the checksums for the Ant jars that >> become part of the SBOM. These checksums are generated from the jars >> built by Maven, which are not identical to the ones generated by Ant. > Do you know what those differences are? Perhaps Maven generates > different content in the JAR file's MANIFEST.MF, which is > understandable. Do you know if this Maven plugin can be instructed to > use the Ant built JAR files? Our build process really isn't repeatable at all - that is a different issue. In my case it may even be that Ant and Maven used different Java versions, I have just abserved them to be different. >> ## Use Maven Plugin for templates and filter magic >> So if the hashes were the main problem, one option could be to generate >> CycloneDX template files we'd commit to git with placeholders for Ant's >> version and checksum hashes. Our release process already copies the POMs >> and replaces the version number, it could also copy SBOM templates and >> replace version numbers and hashes. >> This would require us to re-generate the templates whenever we update >> dependencies, but that doesn't happen often. >> We'd also have to check the jars in lib/optional we build against >> actually are the ones we claim to have used (i.e. verify their hashes, I >> guess). This probably is true anyway, no matter which option we'd use. > I haven't checked what these templates are, so I will have to read up > a bit on that. Oh, there isn't anything to read up. My idea was to run the cyclonedx generation via Maven once manually, take the generated files. Replace checksums and other stuff that may change between releases with some sort of marker - and then commit this set of files to our repository. When we build the release then the build would calculate the checksums and copy the checked in cyclonedx files to the java-repository directory we use for uploads - replacing the placeholders with the real checksums on the fly. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
