Hi,
I have reworked my PR so that using the signing hook is no longer
restrained to a specific platform.
Please note that I have not touched the current code signing
implementation for macOS; to me, it seems simpler to have both options
live side by side, at least for the time being.
If you feel that this is moving into the right direction, I'm thinking
it might be time to remove the draft status on the PR and continue our
discussion on the subject over there. Wdyt?
Thanks,
Frederic
On 13/03/2025 10:39, Magnus Ihse Bursie wrote:
On 2025-03-11 20:29, Frederic Thevenet wrote:
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?
Hm, that is definitely an interesting take. I'm a big fan of
"right-sizing" generalization; I think both too much and too little
generalization is detrimental. My gut feeling right now is that we
should keep this focused on what it is, a way to allow signing. It
will make the functionality discoverable by other parties that would
like to add their own signing script; a general "hook" system might
not. But it's good to keep in mind in case any future, non-signing
needs arise.
I was more thinking along the lines that the current macOS signing
could be considered/rewritten in terms of a "signing hook", with the
exception that we also ship a default implementation alongside in the
build system. If we do that right, we could probably retrofit Oracle's
internal macOS signing logic into the same framework, which would be
nice. But then again, that is definitely feature creep wrt to your
original request. So maybe we can come back and revisit that thought
later.
/Magnus
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
