Re: 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?

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.

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?"

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.

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?

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.

More Like This

Retrieving data ...

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Developer Forums Participation Agreement.