As a long time Java developer, I've only ever had to deal with signing
jar files. I can obviously sign jar files once on whatever platform I
choose to use to build the code, and then distribute the jars to all
platforms. Build once, run everywhere, etc.
However, now that jlink exists, as a developer I have to deal with
signing platform-specific executables. For example, if I distribute a
macOS application produced with jlink, that executable will produce a
large warning message:
Now obviously in the past, the system JRE was signed and so I'd give my
users a jar file, they'd run the jar file using the signed JRE, and
everything would work. With jlink, it's now my responsibility to sign
the executables I produce.
The code signing tools for macOS are evidently not available for any
platform other than macOS, meaning that I now can't just build the code
for all platforms on Linux if I want to use jlink (even though jlink
is capable of producing embedded JREs for all of the platforms I want
to support); at least part of the build would have to take place on
macOS to sign the final result. This is pretty awful!
Are there any plans to implement anything that's capable of signing
macOS binaries and resources in a platform-independent way so that
jlink-produced distributions can work without warnings? Is that even a
reasonable thing to request? I've no idea how "private" Apple keep
their signing implementation.
Re: Signing jlink code for macOS on other platforms
2018/2/12 3:44:07 -0800, Mark Raynsford <[hidden email]>:
> Are there any plans to implement anything that's capable of signing
> macOS binaries and resources in a platform-independent way so that
> jlink-produced distributions can work without warnings?
> Is that even a
> reasonable thing to request? I've no idea how "private" Apple keep
> their signing implementation.
It's certainly reasonable, but as you suggest it would require an
implementation of Apple's signing algorithm that runs on non-macOS
systems. I have no idea if such a thing exists or is even possible.