On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes <and...@openjdk.org> wrote:
>>> Also, it might be worth repeating one of my long-standing wishes: that the >>> version string should not be hard-coded into the build, but e.g. stored as >>> a string in the `release` file, and read from there. If we did that, the >>> cost of changing the version string would be negligible, and we wouldn't >>> need to worry as much about it. It would also be simple to compare >>> different builds which end up with the same bits since they are built from >>> the same sources, but by different version flags (e.g. -ea vs GA). (In >>> fact, we'd turn a -ea build into a GA just by updating the version string, >>> so we'd know for sure we are publishing what we tested.) >> >> +1 >> This would be a great step in making comparability (beyond reproducibility) >> of builds of OpenJDK at lot simpler. > >> Also, it might be worth repeating one of my long-standing wishes: that the >> version string should not be hard-coded into the build, but e.g. stored as a >> string in the `release` file, and read from there. If we did that, the cost >> of changing the version string would be negligible, and we wouldn't need to >> worry as much about it. It would also be simple to compare different builds >> which end up with the same bits since they are built from the same sources, >> but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea >> build into a GA just by updating the version string, so we'd know for sure >> we are publishing what we tested.) > > This certainly sounds like it has the potential to solve a lot of these kind > of problems. I would point out that, if you can flip the EA status in the > text file, someone could also easily masquerade a build as something > completely different from what it is. However, it is already possible to > create a build like this via the `configure` options so it's really only a > slight change in accessibility. > > For example, if I specify `--with-version-feature=11`, I can produce: > > ~~~ > $ /home/andrew/builder/fake11/images/jdk/bin/java -version > openjdk version "11-internal" 2024-09-17 > OpenJDK Runtime Environment (fastdebug build 11-internal-adhoc.andrew.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 11-internal-adhoc.andrew.jdk, mixed > mode, sharing) > > $ /home/andrew/builder/fake11/images/jdk/bin/java -Xinternalversion > OpenJDK 64-Bit Server VM (fastdebug 11-internal-adhoc.andrew.jdk) for > linux-amd64 JRE (11-internal-adhoc.andrew.jdk), built on 2024-03-07T19:41:08Z > with gcc 13.2.1 20230826 > ~~~ > > despite the fact that the source code I've built is actually an > in-development JDK 23. All we'd be doing is moving that into a text file. I agree with @gnu-andrew : the version string reported by the JVM, as it stands today, is only really useful if taken in good faith. If we wanted - or needed - to make it temper-proof from an adversarial threat model standpoint, then we couldn't spare the need for a cryptographically strong solution (which by design would render any direct comparison impossible). Right now, it feels like we are kind of stuck somewhere in-between, incurring all of the drawbacks and none of the benefits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1985459372
