(cc:ing build-dev.)

On 2022-05-12 00:17, Michael Hall wrote:
Is this restricted somehow to Mac App Store applications?

Is a warning issued as stripping native commands  may break application 

Is it not possible for the user to provide their own Info.plist with  a 
different bundle identifier that doesn’t collide?

I’m not real familiar with the build process. But would it be possible for the 
user to build their own jdk that substitutes something else for the colliding 
identifier that gets embedded?
This problem seem to come about as a clash between the the OpenJDK packages themselves being submitted to Apple, as well as a developer-specific jpackage containing JDK binaries, such as java.

The well-written response from Apple tech support in the original web bug is very instructive. I'll quote it in its entirety:

I’ve dealt with this message before, and it has a long and interesting history. The Mac App Store prevents two developers from submitting executables with the same bundle identifier. This is an important security check: We don’t want app A impersonating app B.

This check applies to all executables, not just the app’s main executable. Historically the Mac App Store ingestion process had bugs that caused it to apply to other types of code, like frameworks and bundles. When I first saw this incident I was worried that these bugs had come back.

However, that’s not the case. Let’s look at the main executables in your app:

% find APP_NAME.app -type f -print0 | xargs -0 file | grep "Mach-O.*executable"
APP_NAME.app/Contents/MacOS/APP_NAME: Mach-O 64-bit executable x86_64
APP_NAME.app/Contents/runtime/Contents/Home/bin/java: Mach-O 64-bit executable x86_64 APP_NAME.app/Contents/runtime/Contents/Home/bin/keytool: Mach-O 64-bit executable x86_64 APP_NAME.app/Contents/runtime/Contents/Home/lib/jspawnhelper: Mach-O 64-bit executable x86_64

Based on the error message it’s obvious we need to focus on the `java` executable. However, it’s placed in a location that doesn’t have a corresponding `Info.plist` file:

% find APP_NAME.app -name "Info.plist"

The first file here applies to your entire app and the second file applies to the Java runtime package as a whole. Moreover, neither of these have a bundle ID that matches the error message:

% plutil -extract CFBundleIdentifier raw -o - "APP_NAME.app/Contents/Info.plist"
% plutil -extract CFBundleIdentifier raw -o - "APP_NAME.app/Contents/runtime/Contents/Info.plist"

So where is this bundle ID coming from?

* * *

Some further spelunking reveals the issue. Consider this:

% otool -s __TEXT __info_plist -v APP_NAME.app/Contents/runtime/Contents/Home/bin/java

This is an obscure corner case in the macOS bundle story: A standalone tool, like `java`, which isn’t in a bundle structure, and thus can’t have a standalone `Info.plist` file, can put its information property list in a `__TEXT` / `__info_plist` section within its executable. And it seems that the folks who created your Java runtime did just that.

Given that, the Mac App Store error is valid: You are trying to submit an executable whose bundle ID matches some existing app.

To get around this check you’ll need to give `java` a new bundle ID. That’s not easy to do. This `__TEXT` / `__info_plist` section is set up by a linker option (see `-sectcreate` in <x-man-page://1/ld&gt;) <x-man-page://1/ld>)> and there’s no good way to modify it after the fact [1].

At this point my advice is that you escalate this with your Java runtime vendor. I suspect that they’ve added this information property list to get around a TCC check — the only other interesting property in there is `NSMicrophoneUsageDescription` — and they probably didn’t notice this Mac App Store submission issue. There’s a couple of ways they could resolve this [2] but it’s really their issue to resolve.

[1] And by “good” I mean “Using a standard tool supplied by Apple.” The Mach-O file format is reasonably well documented and thus you could build a custom tool to do that, but even that’s not easy. There are a couple of problems:

* The new information property list may be larger than the previous one.

* The `__info_plist` section can appear anywhere in the `__TEXT` segment.

If you increase the size of the section then subsequent sections need to move up to accommodate it and, depending on which sections you have to move, that might require other cross-section links to be fixed up. Yergh!

[2] The ones that spring to mind are:

* Package the `java` executable in a standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink to that.

* Add an `__info_plist` section with a bunch of padding and then build a tool to update the bundle ID in that section, taking advantage of that padding to avoid the need to move subsequent sections in the `__TEXT` segment.


So maybe a better, or at least alternative, way of dealing with this issue is changing how the OpenJDK binaries are built.

I will need to do some reading up on the macOS bundle format to fully grok what our options are here.


Reply via email to