Providing custom packages for customers

Previous to the notarization requirement, we were able to offer custom downloadable packages (.pkg files) to our customers. This package could include extra information like accountIds or a different subset of the software and such so that when installed the software would be associated with the customers account automatically and have the correct features installed.


We did this by modifying the install scripts and repackaging on the fly then resigning. All of this was done on a linux machine because Apple does not have much support to legally/easily license osx in the cloud.


Now with catalina, and the additional notarization requirement, we could still modify install scripts and resign, but we are unable to notarize the new package for two reasons:

1. It takes a long time and will fail peroidically.

2. We cannot run the notarization and staple from the cloud anyway (without licensing trouble).



My question is this:

Is there a Apple recommended method to provide custom packages for different customers? Some way to add additional parameters to a package without breaking the notarizartion/signing of it?

Replies

Notarization is almost a year old now. It probably would have been better to address these issues then instead of waiting until Catalina is almost released.


I suggest you do the following:

1) Port your Linux scripts to the Mac and start doing all your work there. You can do this in the cloud. There are a number of cloud services that offer legal access to Macs. You'll certainly pay more for this. But if you put things off to the last minute, sometimes you just have to spend your way out of it.

2) Modify your scripts so that if there is a failure, it retries until successful


Once you have it working again you have one of two options:

Option 1) Don't touch it until this time next year when it breaks again for some reason. Hopefully you will have an opportunity to just spend your way out of the problem like you do now.

Option 2) Change your distribution strategy to distribute a static executable. Download any customer-specific resources and store them in /Library/Application Support.

First, even if we can run osx in the cloud with those third parties the notarization process takes far too long to generate on the fly, as outlined in "1. It takes a long time and will fail peroidically."


Second, With respect to distributing a static executable, we have no idea what customer specific resources to download if we cannot customize the package for the customer.


Third, if timelines were not an issue, the question remains, is there an "Is there a Apple recommended method to provide custom packages for different customers? Some way to add additional parameters to a package without breaking the notarizartion/signing of it?"

Let’s wind the clock back to before notarisation was a thing. How did you sign these custom packages?

Share and Enjoy

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

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

We used openssl to create the signatures of the package and then xar to inject the signatures into the package.


To expand on my question, I thought there might be some apple approved way of adding extra information to a package. For instance, it does not appear that xattrs break signing as it inserts things in an alternate file stream, so I thought there might be some way to add additional information to a pkg file after it is signed and notarized. I am not sure if xattrs breaks notarization.

We used

openssl
to create the signatures of the package and then
xar
to inject the signatures into the package.

Well, that’s exciting. It’s also not something that DTS supports )-:

I can’t see any way to update this for the notarisation world. You wrote:

I thought there might be some apple approved way of adding extra information to a package.

No. The notarisation ticket covers the code signature of the package, and the code signature of the package covers the effective contents of that package. This is pretty much required. For example, one of your goals is to tweak the install scripts, but such scripts execute with enormous privileges and thus must be covered by the code signature, and thus covered by the notarisation ticket.

Share and Enjoy

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

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

It’s software. You make it work. If your vendor emails you about a significant change, you make the ncessary changes so that you don’t find yourself in a pickle later.


Otherwise, I don’t know what else to say. Notarization only takes a couple of minutes. If you are experiencing intermittent failures, then investigate them. If a retry succeeds, then do that.


For your downloads, I can think of a number of different solutions. Have your users sign in to an online service with a unique client ID and password. Or generate identical bundles with only a single unique identifier in the plist that will automatically download the bundle. Use whatever method you have now to distribute bundles and instead distribute a setup document that the static app will open.

"Notarization only takes a couple of minutes."


Mmmhhh. I don't know where this number is coming from.


Notarization takes way more than a couple of minutes. It may take a couple of minutes once the archive has been uploaded but the upload process itself can be way more than a couple of minutes.


And the speed issue with the upload does not look like to be on the client machine/network connection but could be either with the altool tool or the notarization server(s).

We're not measuring the decay rate of atomic nuclei or anything.


I just did a test using purely interactive Xcode.

9:21:00 Xcode > Product > Archive

9:25:50 upload complete, please wait

9:27:31 Your Mac software has been notarized. You can now export this software and distribute it directly to users.


Given the completely subjective and qualitative nature of my "couple of minutes" estimate, I'm going to go ahead and call my this estimate "pretty accurate". Note that it did take you 19 days to even reply. Given that most Apple developers are developing for the App Store, a 6:31 total time to notarization is much better than even the fastest (successful) app review and app store update, which is really what we should be comparing against here. Is that really so bad? If you did do all of this on a Mac cloud service, distributed over 10 instances, your app notarization rate would be under one a minute. If you are pushing out software to paying customers at that rate, why are we even having this conversation? Shouldn't you be sitting on the beach on your private island or something?

I hope that a delay of 11 days for the reply is not going to cause you a psychological shock again.


So I performed tests on my side and the outputs are a bit less optimistic than yours:


- time to build the products and the archives to upload: ~2 minutes

- time to upload the archives: ~4 minutes.

- time for the notarization process to be performed on the server and the result to be available: 2-3 minutes.


So basically, this means multiplying the a job build time by 4 on a CI server.


I'm glad this is not an issue for you. For me, it is.


Of course, these results were before the release of macOS Catalina.


Because, since then, the time a notarization request can take on Apple's server has quite increased:


- in the best cases, it takes 3-4 minutes.

- it's no more uncommon for it to take 9-10 minutes. And having to wait 10 minutes is quite irritating.

- worst case I've experienced so far was 30 minutes.


And if I am to believe the feedback I'm seeing in the forums, there are even worse cases.


Regarding the private island idea, considering that an app is worth $0.99 or nothing on Apple's platforms, I find the scenario you suggested a bit unrealistic.