On 2022-05-23 19:16, Andrew Leonard wrote:
Hi, Has anyone looked into reproducible builds for codesign'd MacOS builds? Basically Apple codesigning is non-deterministic, which is not surprisingly I guess, so naturally makes reproducible builds a bit tricky. The general theme for this sort of issue seems to be to remove the signature before comparing (codesign --remove-signature X.dylib). Which i've attempted, and works to a degree. The single stumbling block being the signing of jpackageapplauncher in jdk.jpackage, which then gets placed in the jmod's classes resource section, leading to different module "hash" in java.base/../module-info.class, and also a different "modules" file. Has anyone else tried to tackle this problem? Could we store jpackageapplauncher somewhere that would not end up in the jmod classes...but still be securely loadable? ( https://github.com/openjdk/jdk/blob/646c8aaeeccb494c72ff84c6e0f303f790be0ba9/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L284
Unfortunately, I think this is an unsolvable problem. :-( We need to package all needed resources with the jmod, and jdk.jpackage needs its launchers. If we were do to anything differently, then suddenly the jdk.jpackage module would be different -- you will not be able to create a stripped-down image containing jdk.jpackage that will work properly, without also copying the launcher on the side.
If anything, I suggest you create an image without jdk.jpackage, if you want to have a reproducible build on macOS.
Personally, I have not spent much time and effort yet looking at reproducibility on macOS. I think we have quite some way to go there, compared with Linux and Windows.
/Magnus
