Append data of personalized installer

Question

Created Oct ’24

Replies 3

Boosts 0

Participants 2

Hi our team is looking into feasibilities of appending customized data to personalized installer, so that we can make new users onboarding experience better. I did some investigations.

Append token data to xattr to a dmg, I went though this smoothly. I can successfully retrieve the data back, and the app can still be launched successfully. Want to make sure this doesn't require the dmg to be re-signed and re-notarized, and I didn't miss any steps in between
I created a fake simulation app try to sign and notarize. Signing the dmg seems to be successful, but when I notarize, it gave me back Invalid status. Is there anything wrong?

This is the signature: Executable=/Users/myname/myname/poc/MySimulation.dmg Identifier=MySimulation Format=disk image CodeDirectory v=20200 size=304 flags=0x0(none) hashes=1+6 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=e2a149614f6e0e3939db3a 4c762adda0e8c24
CandidateCDHashFull sha256=e2a149614f6e0e3939db3a3054adda0e8c24f597ddf4c4503cd27fb83821 Hash choices=sha256 CMSDigest=e2a149614f6e0e3939dba3054c62adda0e8c24f597ddf4c4503cd27fb83821 CMSDigestType=2 CDHash=e2a149614f6e0e39393a3054c762adda0e8c24 Signature size=4789 Authority=Apple Development: myId (someId) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=Oct 14, 2024 at 3:46:08 PM Info.plist=not bound TeamIdentifier=W3TC3HXUZC Sealed Resources=none Internal requirements count=1 size=188

Do you have any other recommendations for us to append some data that doesn't break signing / notarization?

Answered by DTS Engineer in 809630022

My preferred option for this is to set an extended attribute on the app rather than on the disk image. Specifically, the com.apple.application-instance extended attribute, which is specifically (albeit obscurely :-) documented for this sort of thing. See the discussion in TN2206 macOS Code Signing In Depth [1].

The upsides to this approach are:

It’s actually a documented and supported use case.
You don’t have to do anything gnarly to get things working when your app is translocated.

The main downside is that this attribute is within your disk image. That means you’ll have to rebuild the disk image on the fly for each user. That’s not a problem from a signing and notarisation perspective: The system doesn’t require that disk images be notarised, so you can sign and notarise your app and you’re done. However, it make present infrastructure problems because building disk images is something you do on the Mac.

One way around that is to move from a disk image to a zip archive.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] It’s weird referencing TN2206 again. I used to reference it all the time, but these days we have much better code signing documentation. Yay!

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’24

I’d like to get a better understanding of your requirements here. Here’s what I think is going on:

You have a Mac product that you distribute directly (as opposed to on the Mac App Store).
Your users download that product from your website.
At the point of download, you want to customise the product for each user.

Am I right so far?

If so, I have a couple of follow-up questions:

Roughly how many users are we talking about here? Tens? Hundreds? Thousands?
How is your product currently packaged. You mentioned an disk image, so I’m presuming that’s the outermost container. What’s on that disk image? Just your app? Is there more nested containers, like an installer package?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

wangsnowyin OP

Oct ’24

Thanks for the quick reply! Yes the 3 points of the requirements are correct

The number of users we are expecting will be more than thousands in total potentially, but for per day we are anticipating hundreds as the starting point
The disk image contains app bundle with Contents/MacOS which contains the main app and several other executables; also Contents/Resources/ contains resources files; also Info.plist as well as the codeSignature

I have tried appending xattr to a downloaded dmg, and it still launches successfully. Wondering whether this is one of the feasible solutions, any limitations there. And other suggestions are super welcomed too!

0

Answer 3

DTS Engineer OP

Apple

Oct ’24

Recommended

My preferred option for this is to set an extended attribute on the app rather than on the disk image. Specifically, the com.apple.application-instance extended attribute, which is specifically (albeit obscurely :-) documented for this sort of thing. See the discussion in TN2206 macOS Code Signing In Depth [1].

The upsides to this approach are:

It’s actually a documented and supported use case.
You don’t have to do anything gnarly to get things working when your app is translocated.

The main downside is that this attribute is within your disk image. That means you’ll have to rebuild the disk image on the fly for each user. That’s not a problem from a signing and notarisation perspective: The system doesn’t require that disk images be notarised, so you can sign and notarise your app and you’re done. However, it make present infrastructure problems because building disk images is something you do on the Mac.

One way around that is to move from a disk image to a zip archive.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] It’s weird referencing TN2206 again. I used to reference it all the time, but these days we have much better code signing documentation. Yay!

0