(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
functionality?
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"
APP_NAME.app/Contents/Info.plist
APP_NAME.app/Contents/runtime/Contents/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"
UNIQUE.BUNDLE.ID
% plutil -extract CFBundleIdentifier raw -o -
"APP_NAME.app/Contents/runtime/Contents/Info.plist"
com.oracle.java.com.UNIQUE.BUNDLE.ID
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
…
<dict>
<key>CFBundleIdentifier</key>
<string>net.java.openjdk.java</string>
…
</dict>
</plist>
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>)
<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.
/Magnus
