RFR: 8350801: Add a code signing hook to the JDK build system

[Magnus Ihse Bursie]

On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> OpenJDK vendors who provide binary distributions for the Windows and macOS platforms generally need to ensure that every native executable file and dynamic library that are part of the binary builds are digitally signed using a set of OS specific APIs.
> 
> The JDK build systems already provides the ability to invoke Apple code signing API during the build on macOS, but there is no equivalent support for Windows.which 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, in particular with regard to the introduction of JEP 493.
> 
> This change aims to solve this by introducing a "signing hook" that users can use to specify a custom script that will be invoked by the build system for every native executable of library compiled and linked as part of the build target.
> This is to provide enough flexibility for each vendor to include their own specific configuration and/or signing logic, not limited to a specific set of platforms.

We have a macro `UTIL_FIXUP_PATH`, but I honestly thought it was called automatically for TYPE `file`. But maybe we don't. Just add a call to it with the name of the variable to fix, and any relative paths will be resolved and replaced with an absolute path in spec.gmk.

Actually, I think there is a UTIL_FIXUP_EXECUTABLE, which takes care of adding FIXPATH and fixes any issues with `.exe` on Windows. That is the one you should use.

Also, the addition of the `executable` test was good! Please re-instantiate it. 

I'm not sure if @tstuefe meant that it should be removed? If so, why? To be able to pass in a shell script that does not have the executable bit set? That's kind of weird. How do we even know it is a bash script then? It might just as well be a ksh or csh script, so just assuming bash would be strange. 

If, for some reason, you want to run a bash script without using normal shebang and x bit, then you'd have to tell configure this explicitly: `configure --with-signing-hook="bash ../my-weird-script.sh"`

make/autoconf/jdk-options.m4 line 996:

> 994:     SIGNING_HOOK_ENABLED=true
> 995:     AC_SUBST(SIGNING_HOOK)
> 996:     AC_MSG_RESULT([yes])

Suggestion:


  AC_MSG_CHECKING([for signing hook])

...

        AC_MSG_RESULT([$SIGNING_HOOK])

...

        AC_MSG_RESULT([none])

make/common/NativeCompilation.gmk line 244:

> 242: 
> 243:   $1 += $$($1_CALL_SIGNING_HOOK)
> 244: endef

You can simplify this, so you get rid of `SIGNING_HOOK_ENABLED`. Also, FIXPATH is not needed after the call to `UTIL_FIXUP_EXECUTABLE`.

Suggestion:

define CallSigningHook
  ifneq ($(SIGNING_HOOK), )
    # Create a rule to call post-link signing hook
    $1_SIGNING_OUTPUT_PREFIX := $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_call_signing_hook
    $1_CALL_SIGNING_HOOK := $$($1_SIGNING_OUTPUT_PREFIX).log

    $$($1_CALL_SIGNING_HOOK): $$($1_TARGET)
	$$(call LogInfo, Signing $$($1_BASENAME))
	$$(call ExecuteWithLog, $$($1_SIGNING_OUTPUT_PREFIX), \
	    $(SIGNING_HOOK) $$($1_TARGET))

    $1 += $$($1_CALL_SIGNING_HOOK)
  endif
endef

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2749359559
PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2749361163
PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2750938087
PR Review Comment: https://git.openjdk.org/jdk/pull/23807#discussion_r2011888277
PR Review Comment: https://git.openjdk.org/jdk/pull/23807#discussion_r2011877421