Possible to notarize only a single binary in a package?

Question

Ken Hornstein OP

Created Apr ’20

Replies 1

Boosts 0

Participants 2

Hi,

Thank you, eskimo and John, for replying to my earlier message; I was able to get all of my tools successfully signed and notarized! However, this brought up a question from a fellow group of software developers and I wanted to ask people here.

The fellow developers are distributing a proprietary Java application. The Java runtime they use is open-source, but their proprietary bits are in the .jar files. This application is not distributed to the Mac store, but only made available to their customers.

They complained to me about the hassles of Gatekeeper on Catalina (because they knew I was working on in for the software I am working on, and their software package uses components of what I am working on). Their primary concern is that they didn't want to upload their .jar files to Apple since that's their proprietary bits.

But, this brings up my question. This is again a bit of a corner case, because it's a little opaque to me at least how the connection between the file you submit with altool and the notarization ticket applied with stapler all works. My understanding is the only true Mach-O binaries that they ship is the Java runtime and all of the associated components. One thing that has been mentioned is that you can upload a zip file to be notarized. Would it be possible to correctly sign the Java runtime, just zip up the runtime components, submit THAT for notarization, and then once notarization is complete they can use stapler to staple the notarization ticket to their package (which includes the proprietary components they don't want distributed). If it matters at all, I am not sure if internally things are arranged as a Unix command-line tool or an app bundle.

--Ken

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’20

The notarisation ticket is effectively a list of cdhash values that’s been signed by Apple. A cdhash, or code directory hash, is the way that the system uniquely identifies native code. For example:

% codesign -d -vvv /usr/bin/true 
…
CDHash=b78bf78510f0b95bee1f259cee767bcdbc10c7aa
…

If you have a big bag of native code and you want to notarise all of it, you can put that into an supported container (like a zip archive), notarise that, and you’re done. You can then rearrange the code into some final distribution format if you want.

However, things get tricky when it comes to nesting. If you have a bundle with nested stuff, the cdhash for the bundle will change if the nested stuff changes. That’s a pretty obvious requirement when you think about it from a Gatekeeper perspective.

My experience with Java apps is that they generally ship as a double-clickable app, with all the jar archives embedded within that app. That means that you can’t submit the app without submitted the jar archives because putting the jar archives back into place would break the code signature.

You could, I guess, ship the jar archives outside of the app, and only notarise the app, but that kinda defeats the whole purpose of code signing. Remember that the goal here is to stop users running malicious code, and if your app loads and runs Java code that’s not covered by a code signature then you’re working counter to that goal.

Oh, and one more thing: Jar archives can contain native code. If that’s the case here, you have to notarise the jar archive — or, at a minimum, the native bits within the jar archive — because otherwise its cdhash won’t end up in the ticket.

Their primary concern is that they didn't want to upload their .jar files to Apple since that's their proprietary bits.

Hmmm, that doesn’t make sense to me. They’re worried about submitting these jar archives to Apple for notarisation, but then they go and hand them out to customers. *shrug*

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0