Sign the Mach-O binaries that travel inside the jars
STEPSS 3.82 was signed, built and then rejected by Apple with "Archive
contains critical validation errors". The notary service opens jar files
and inspects the Mach-O binaries inside them; jpackage does not. It signs
the .app and the runtime it assembles and copies --input verbatim into
Contents/app, so FlatLaf's four macOS dylibs reached Apple unsigned, two
in flatlaf-3.7.2.jar and the same two again in the fat stepss.jar that
-post-jar merges them into. The engines are unaffected: they ride along
as .tar.gz resources, which the notary does not open.
tools/jar-natives.py finds them by magic number rather than by name. The
extension is no guide: FlatLaf says .dylib, the JNI convention used to be
.jnilib, and a library may ship one under no extension at all. The four
thin magics settle it outright; the fat magic does not, because 0xCAFEBABE
is also the magic of every Java class file, and stepss.jar holds 4017 of
those. A fat header is therefore parsed rather than matched, and counts
only if its slice table is consistent: a plausible slice count, every
slice inside the file, and each one starting with a thin Mach-O magic of
its own. On the real jars that reports the four dylibs and nothing else.
Write-back is an Info-ZIP update, which copies every untouched entry
across verbatim. Compared before and after, both jars keep their entry
count, their order, and every other entry's name, CRC, size, compression
method, timestamp, attributes and bytes; only the two signed entries
differ, and only in length and mtime.
The signing itself is sign.sh from SPS-L/stepss-ci, so the Developer ID
identity, the secure timestamp, the hardened runtime and the entitlements
stay in one place. It is called as a script rather than through the
composite action because the action opens a keychain of its own and this
job already has one open at that path.
lib/ is signed as well as dist/, which is what makes the fix stick.
`ant bundle` depends on the jar target, so the installer build rebuilds
dist/ from lib/ before jpackage runs: a marker appended to the dylibs in
dist/ was gone after the next `ant jar`, while one written into lib/
propagated into dist/lib/ and into dist/stepss.jar. A new step after the
build re-reads dist/ and verifies every signature there, and both
commands fail when they find no binaries at all, because a scan finding
nothing is exactly what this looked like before the fix existed.
Both architectures are signed. The bundle ships arm64 only, but Apple
objected to the x86_64 slice too, and removing a file from a third-party
jar changes what that library ships.
Claude-Session: https://claude.ai/code/session_01GxELE42yLRLQQ1g4bwnJGj