mirror of
https://github.com/wgtunnel/Nucleus.git
synced 2026-10-09 14:40:54 -07:00
takkeandClaude Fable 5.1
76a10c06f0
Developer ID signing of a GraalVM native-image .app failed in
packageGraalvm<Format> ("code object is not signed at all / In
subcomponent: Contents/MacOS/.nucleus-executable-type"), and even after
that Gatekeeper rejected the notarized bundle. Three independent causes:
1. The executable-type marker was written into Contents/MacOS/, which
codesign treats as nested code. Write it to Contents/Resources/ on
macOS and let ExecutableRuntime look in both places (old location
first for compatibility).
2. resignApp() only re-signed Contents/runtime and Contents/Frameworks,
so the GraalVM dylibs in Contents/MacOS/ and Contents/MacOS/lib/ kept
their ad-hoc signature and notarization rejected them. Sign them
inside-out like the JVM runtime directory.
3. fontconfig.bfc shipped in Contents/MacOS/lib/. Gatekeeper treats
every file below Contents/MacOS/ as code, so the notarized, stapled
bundle still got "spctl: rejected". Ship it in Contents/Resources/
and point the JDK at it via sun.awt.fontconfig from
GraalVmInitializer.
Verified with a real app: notarytool Accepted, stapled, all 16 Mach-O
files Developer ID signed with hardened runtime, and
`spctl -a -t exec` now answers "accepted / Notarized Developer ID".
The JVM (jpackage) pipeline is unaffected.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>