Package Details: jdk21-openj9-bin 21.0.5b11_openj9_0.48.0-2

Git Clone URL: https://aur.archlinux.org/jdk21-openj9-bin.git (read-only, click to copy)
Package Base: jdk21-openj9-bin
Description: IBM Semeru OpenJ9 with openjdk21
Upstream URL: https://developer.ibm.com/languages/java/semeru-runtimes/downloads
Licenses: custom
Conflicts: jdk21-openj9, jdk21-openj9-bin
Provides: java-environment, java-environment-openjdk, java-runtime, java-runtime-headless, java-runtime-headless-openjdk, java-runtime-openjdk
Submitter: rubin55
Maintainer: rubin55
Last Packager: rubin55
Votes: 2
Popularity: 0.55
First Submitted: 2024-08-24 08:33 (UTC)
Last Updated: 2024-11-14 09:36 (UTC)

Required by (2726)

Sources (1)

Latest Comments

rubin55 commented on 2024-10-07 12:58 (UTC)

I've looked into this together with peeps from IBM. What happened (in their words):

"There was an initial release with SHA 757e1ee92666 which had "-rc1" in the vendor version (but not in the archive file name). We rebuilt it to remove that and replaced the release. There should be no other changes, although perhaps rebuilding cacerts made some small difference. I'm surprised that is the only change, the binaries should be different as it was a completely new build."

The archive does indeed match the hash I had initially, but it does not contain an altered cacerts file (but instead a whole slew of binary files that differ, which is expected, because they probably contain a version string with -rc1 appended). On my end, I think I compared the wrong files on my two different systems, where the system running the "old" version was actually updated already. Maybe the makepkg build process or some other certificate management utility touches cacerts in a way that does change the hash of that file, but I'm not sure yet where/why/how that happens.

TL;DR; IBM replaced binary archive without mention, which triggered the hash change, I did a faulty compare which highlighted cacerts. Replaced and new archive do not contain differences indicating tampering, need to still figure out where that diff on cacerts comes from, which probably has to do with Arch itself.

rubin55 commented on 2024-10-04 08:01 (UTC)

I've created a security report with the openj9 project on GitHub, I don't know a better place to file a possible security issue with this one. It might all turn out to be a nothingburger. The report is confidential, so I don't think I can share it here. Will keep updated with any findings.

rubin55 commented on 2024-10-04 07:15 (UTC) (edited on 2024-10-07 13:03 (UTC) by rubin55)

@binarynoise, there is one difference:

my previously packaged version:

529e4d0cb73ab270263024fb215f49d74555ff00d32cdab6fd19396971358e2b /usr/lib/jvm/java-21-j9/lib/security/cacerts

the version now existing upstream:

0bc46840bd30f4c8cc60e433b66077e669077f548453b1889a6e8872ab4f5691 /usr/lib/jvm/java-21-j9/lib/security/cacerts

I'm going to file an issue upstream; way it looks like, cacerts changed. I don't think this is an issue on my end, this is quite disconcertening imho.

rubin55 commented on 2024-10-04 07:01 (UTC)

@binarynoise, I must have made a mistake; I replaced the hash with the upstream hash in their sha256sum.txt, the package should build again. I am a bit puzzled, because I made this package on the day that the release came out and I built the package without failing the hash check. Maybe my download was corrupted but it still unpacked correctly (unlikely)?

In any case, it should work now. I am going to do a bit more digging to see if there are important content differences.

rubin55 commented on 2024-10-04 06:37 (UTC)

@binarynoise, I think that the binary upstream changed actually; I'm 99.9% sure it sha256sum passed and I have the package installed. I'll see if another system still has the matching binary.

binarynoise commented on 2024-10-03 16:39 (UTC)

sha256sum doesn't match, something might have got mixed up in the last update