[Proposal] Add code signing on Windows to the JDK build system

Tue Mar 11 19:29:41 UTC 2025

Hi Magnus,

As mentioned before, the core idea here is really just providing a hook 
for a script to be invoked after the native linker has been called.
So while thinking about making this more generic and not Windows 
specific, it struck me that it might in fact be desirable to also drop 
the "signing" notion from this altogether and instead consider it a way 
to extend to the build system by plugging in custom scripts? And maybe 
extend it with other strategically placed hooks?

Do you think this is a direction worth exploring further? Or that the 
original, more focused scope is preferable?

Thanks,
Frederic

On 07/03/2025 16:49, Magnus Ihse Bursie wrote:
> Hi Frederic,
>
> I think your proposal makes sense, and as Erik says, the patch is very 
> unobtrusive.
>
> I'm not at all sure if it is even possible, but if the signing logic 
> for macOS and Windows can be sort of unified and made more abstract, 
> that would certainly be a win.
>
> /Magnus
>
>
> On 2025-02-26 20:46, Erik Joelsson wrote:
>> On 2/26/25 10:40 AM, Frederic Thevenet wrote:
>>> Hi Erik,
>>>
>>> Thanks for your comments.
>>>
>>> As a matter of fact, we at Red Hat also face similar constraints 
>>> that prevent us from being able to sign the files on the machine 
>>> that build them (and I suspect this is quite common-place).
>>>
>>> My initial idea to accommodate that is to have the jdk build invoke 
>>> a user supplied script (via a --with configure argument) rather than 
>>> having it call signtool directly, so as to provide a way for 
>>> everyone to easily plug their specific configuration and logic (in 
>>> our case, the script uploads the file to sign to the signing machine 
>>> and download it once it is done, in a synchronous fashion).
>>>
>>> In effect, it's just a hook that is invoked after the native linker 
>>> has been called.
>>>
>>> I have created a PR[1] where you can see what I've done in details.
>>
>> That's a small and unintrusive solution. Our solution is a lot more 
>> involved as I figured I wanted to expose a set of top level "phase" 
>> targets for signing for each module, so that building libs or 
>> launchers can be done independently from signing (e.g. 
>> java.base-libs, java.base-launchers and java.base-sign). This 
>> necessitates a separate set of output directories for signed libs and 
>> signed launchers, where we first build like normal to the regular 
>> output dirs and then the sign target copies and signs binaries into 
>> the *-signed outputdirs, and when building jmods, we need to pick up 
>> the files from those *-signed directories. It's quite messy, so I've 
>> kept it all in our internal makefile extensions. I'm also questioning 
>> the usefulness of this flexibility given how much complexity it adds, 
>> so your proposal is probably preferred.
>>
>> That said, I'm wondering if we could make it a bit more generic and 
>> not define it as "windows" specific? Then perhaps bake in the macos 
>> signing logic into this as well. The default implementation could be 
>> using the native OS tools while there is a configure option to 
>> completely replace it.
>>
>> /Erik
>>
>>>
>>> Thanks,
>>> Frederic
>>>
>>> [1] https://github.com/openjdk/jdk/pull/23807
>>>
>>> On 26/02/2025 15:29, Erik Joelsson wrote:
>>>> 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
>>>>>
>>>>
>>>
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92