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

Reply via email to