On Wed, 26 Feb 2025 18:02:53 GMT, Frederic Thevenet <ftheve...@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. > Tested on Mac OS. Works, see > [build.log](https://github.com/user-attachments/files/19428633/build.log) > > Improvement possible: > > * signing script has to be executable I've extend the `UTIL_ARG_WITH` macro with a new type to check that the provided argument is indeed an existing file with execute access under the current context, so now `configure` should fail if a non executable script is provided. > > * only works with absolute path names for the signing script This is indeed expected since the current directory is not the same at the time when the script's path is capture and when it is executed. One way to work around that would be to resolve any relative path provided to `configure` via `UTIL_ARG_WITH` to an absolute path for later use; I was thinking about using `realpath` for that but I don't know how portable this is, especially on macOS, as I've read some conflicting reports on that and don't has a mac handy to check myself (FWIW, it is available on both Cygwin and MSYS2 on Windows). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23807#issuecomment-2748953536
