+1 (binding?) Claude.ai did the work, which was strictly focused on verifying artifacts across the distributions, comparing them with the sbom checksums and those in the maven repo.
I am assuming everything works, so my concern is just *is it packaged correctly*. All is good. This is the first time I've worried about SBOM validation, which new feature. First time I've come across an asf binary tarball with one, FWIW. Nice. Will probably be mandatory once the EU CRA goes live. three things which can now be validated - are there any unlisted artifacts - is there anything listed that is missing - do the checksums match All seemed good, at least as far as claude claims. Steve ---- # Apache Ant 1.10.18 RC1 — validation report Vote thread: https://lists.apache.org/thread/yv41t5b4g887qdd03n38chr67vcwh55x Dist: https://dist.apache.org/repos/dist/dev/ant/ (binaries/, source/, manual/) Maven: https://repository.apache.org/content/repositories/orgapacheant-1079/org/apache/ant/ ## Result: everything checks out ## 1. Distribution fetch 109 files pulled from dist/dev/ant: 36 each in binaries/, source/, manual/ (4 archive formats x {archive, .cdx.json, .cdx.xml} x {file, .asc, .sha512}), plus RELEASE-NOTES-1.10.18.html. Every artifact has both a .sha512 and a .asc. Only RELEASE-NOTES has neither, which is normal. ## 2. Checksums and signatures - 36/36 .sha512 files match. No mismatches. - 36/36 .asc signatures good. All signed by subkey 6A93161EB1990E8346E7BA2B23738DFD7C40DE43 of pub ed25519 2024-12-30 [SC] BC26C53AF531F8B4B3F5930AAFBD3AF8EAFA72DA uid Stefan Bodewig <[email protected]> Trust chain: the key is published in https://downloads.apache.org/ant/KEYS and independently at https://people.apache.org/keys/committer/bodewig.asc (ASF LDAP-backed). It is also cross-signed by Bodewig's long-standing 2001 DSA key A2115AE15F6B8B72 and by his innoq key 0BF6E64A4B6CD3A9. Good. ## 3. Archive contents vs CycloneDX SBOMs For each of the 12 archives, against both the .cdx.json and .cdx.xml (24 runs): - metadata.component hashes recomputed over the archive itself, all 8 algorithms (MD5, SHA-1, SHA-256/384/512, SHA3-256/384/512) — all match - every `type: file` component located in the extracted tree - every file in the extracted tree present as a component - all 8 hashes recomputed per file | dist | files | libs | missing | extra | hash mismatches | |--------|-------|------|---------|-------|-----------------| | bin | 1725 | 19 | 0 | 0 | 0 | | src | 2446 | 0 | 0 | 0 | 0 | | manual | 1579 | 0 | 0 | 0 | 0 | Nothing extra, nothing missing, every checksum matches. The 19 `library` components in the binary SBOM are the declared external dependencies (antlr, bcel, bsf, commons-net 3.13.0, jsch, jakarta.mail, javax.mail, junit 4.13.2, junit-platform-launcher 1.10.5, log4j, oro, regexp, xalan 2.7.3, xml-resolver, xz 1.9, jai, jdepend, commons-logging, netrexx). They carry no hashes, as expected — they are not shipped. ## 4. SBOM cross-comparison For each distribution: - .cdx.json vs .cdx.xml for the same archive: identical inventory (file set, every hash, library set and all library metadata) — 12/12 pairs - tar.gz vs tar.bz2 vs tar.xz vs zip: identical inventory — 9/9 comparisons So the .tar.bz2, .tar.xz and .zip describe exactly the same contents as the .tar.gz in every case. Only the metadata.component archive hashes differ, as they must. ## 5. Maven staging repo (orgapacheant-1079) 792 files across 27 artifacts (26 jar artifacts + ant-parent pom). - 528/528 .md5 and .sha1 files match - 132/132 .asc signatures good, same key as the dist artifacts - 52 per-artifact SBOMs (26 x json/xml): metadata.component hashes match the corresponding jar across all 8 algorithms ### Maven vs binary distribution Compared every `<artifact>-1.10.18.{jar,pom,cdx.json,cdx.xml}` in the staging repo against `lib/<artifact>.{jar,pom,cdx.json,cdx.xml}` in the binary dist: 105 files byte-identical, 0 differ, 0 present on only one side (26 artifacts x 4 files + ant-parent.pom = 105. ant-parent is pom-only, and its pom is present in lib/ too.) ### Maven sources jars vs source distribution 949 source files across the 26 -sources.jar files, checked against the src tarball: 931 byte-identical 18 differ only by a trailing newline 0 other differences 0 files absent from the source distribution The 18 files (Dirname.java, TaskContainer.java, the launcher/* classes, Javah.java, ReadableSelector/WritableSelector, ScriptManager, CloseResources, Retry, two junitlauncher package-info) have no final newline in the sources jar; the src tarball has one. The jar matches git exactly (those files end with `}` and no newline in the repo) — the src tarball is the one that is normalised, by the <fixcrlf> pass in the dist target. Cosmetic, pre-existing, not a blocker. ## 6. Smoke tests - Binary dist: `bin/ant -version` -> "Apache Ant(TM) version 1.10.18 compiled on September 3 2026" - Source dist: `sh ./build.sh dist-lite` -> BUILD SUCCESSFUL, and the resulting ant reports version 1.10.18 - ant.jar manifest: Specification-Version and Implementation-Version both 1.10.18 - All poms are 1.10.18 (the only other version string is the junit-platform-launcher 1.10.5 dependency) - LICENSE and NOTICE present in all three distributions - Binary dist lib/ contains only org.apache.ant jars — no bundled third-party code - Release notes and WHATSNEW both say 1.10.18 (from 1.10.17) ## Notes, none blocking 1. The sources-jar / src-tarball trailing-newline difference above (18 files). 2. The source distribution ships 5 jars: `lib/optional/hamcrest-3.0.jar`, `lib/optional/junit-4.13.2.jar` (test deps, pulled in by the `<fileset dir="lib/optional" includes="*.jar"/>` at build.xml:132) and three signature-test fixtures under `src/etc/testcases/taskdefs/conditions/jars/`. Identical to 1.10.17, so pre-existing, but the two lib/optional jars are third-party binaries in a source release. 3. The manually-created SBOM sha512 files for the manual tarballs (the reason for the two svn commits) all verify correctly. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
