Hello,
I think this is a reasonable idea and you are welcome to implement it.
At Oracle we have been solving this using custom extension makefiles.
That will unfortunately not change with this proposal as our signing
process does not involve direct access to the native tools of the OS.
Perhaps this implementation could be made plug-able enough so that we
could leverage it, I'm not sure. What I'm trying to say is that we are
not against this, but we are also not inclined to invest resources into it.
/Erik
On 2/26/25 12:52 AM, Frederic Thevenet wrote:
Hi,
I would like to start a discussion about adding built-in support for
code signing native executable file and dynamic library on Windows
directly as part of the JDK build, in a similar fashion to what
already exists for macOS.
Most, if not all vendors already ensure that every native executable
files and dynamic libraries that are part of the binary builds of
OpenJDK that they distribute to their customers for the Windows
platform are digitally signed using a set of Microsoft APIs and tools
called Authenticode[1].
Since this is not a part of the existing JDK build system, however,
this means that each vendor has had to come up with their own way to
integrate the code signing step into their build pipeline.
As the shape of the JDK binary deliverable evolved to accommodate
features like modules, signing binaries as an after-the-fact process
has gradually become more complicated and error prone.
For instance, with the introduction of JEP 493 (Linking Run-Time
Images without JMODs)[2], adding a digital signature to files after
jlink runs as part of the build to create the JDK image when the new
'--generate-linkable-runtime' feature is enabled will cause any
subsequent uses of jlink from this image to fail with a "Error:<xxxx>
has been modified" error.
The solution to that particular problem is to ensure that the
signature is applied before jlink generates the checksums it will
later use to detect , and I believe the best way to achieve that is to
integrate code signing as an option in the jdk build process.
This would also offer vendors who decide to opt into using this new
feature to potentially simplify their overall build process.
For instance, this could get rid of extra steps such as filtering out
dlls that are part of the bundle but were not built as part of the jdk
(e.g. the Microsoft C and C++ runtime redistributables), or making
sure that 'exe' and 'dll' files packaged in the .jmod files are also
signed.
As a stated before a very similar option already exists for code
signing on the macOS platform, which further reinforce my thinking
that such a feature would make sense for Windows as well.
I have drafted a prototype for this and would be happy to create JBS
issue and submit a PR to move this forward, provided there is interest.
Thanks,
Frederic Thevenet (fthevenet)
[1]
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)
[2] https://openjdk.org/jeps/493
