RFR: 8327389: Remove use of HOTSPOT_BUILD_USER

[Frederic Thevenet]

On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes <andrew at 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