On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet <[email protected]>
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
