Is frequent notarization allowed?

Hi,


we run automated builds and package creation using a build-machine. The machine checks every hour, if some source code in GIT repository has changed. If changes are detected, it will build, package and sign the affected products. By this, if some developers are busy, it will build and sign the same app up to 8 times a day.


The benefit is, that the most recent builds simply can get copied and sent to testers and they test an app like getting deployed from the beginning. It would be very good for handling in QA etc. Also, QA testers do not need to notarize and install/use XCode. More like everyday users.


I just wonder if I'm allowed to also add notarization to the build scripts? In this case, the same app (which is mostly never deployed) is notarized many times. If Apple stores every notarization of every version of the app in it's database, it would grow rapidly. They very likely do not want me to do this. Or is this no problem?


What do you think? Is there any documentation telling me "when" to notarize and "how often" I'm allowed to notarize even only QA builds?


Thanks,


Kukulkan

Replies

There are absolutely no restrictions on the number of notarization requests sent to the Apple server.


The only limitation you will face these days is the performance issue of the notarization server/service.


Which means that your automated build process will at least be around 6 minutes longer.

Thanks. But is there any place where I can read this? Any official source for this? I really do not want them to close our account because of "missuse" or whatever this may trigger then...


Also, what if I notarize my app in version 1.1.1, then later version 1.1.2 and finally version 1.1.3. If i now decide to release version 1.1.2; do I have to re-notarize version 1.1.2 or are all three versions valid then?

Companies aren't going to post any official statements like this anymore. I can't imagine they would close your account for this, but I also don't have authority to speak on Apple's behalf. Your Apple Developer program does have a number of "interference" clauses that could be used against people trying to undermine Apple's security infrastructure. It sounds unlikely that you would ever qualify under that, but accidents do happen.


On a more fundamental level, I would question whether it is a good idea to automatically distribute the results of automated builds. I'm aware that this the hip thing to do these days. But it also opens you up to potential vulnerabilities. Your app could be used as a malware distribution host. I know it is far-fetched, but it has been successfully used in the past on multiple occasions.


All that said, I don't think 8 a day is very many. I think I've done more than that when working towards a release.


Notarization is not version-sensitive. Old versions are still notarized.

Thanks for your answer. We do not distribute or upload these builds. This is building for QA. They get the .pkg packages by email or download for testing. And of course, I want them to test like real end users. But manually notarizing them is to time consuming and it is better to do this in the build script. And this runs very often.


And at one point, we take such and upload it for the public. It has to stay notarized, even if we build new versions later (eg for patch releases).


I think I can try this. We will see if something happens :-)


Have a nice weekend.

Is there any documentation telling me "when" to notarize and "how often" I'm allowed to notarize even only QA builds?

I discussed this overall issue with the notarisation team and our conclusion is that we need to think carefully before offering official advice on this topic. I filed a bug requesting that we do that, and then add that advice to our documentation (r. 56675410).

My personal take on this is that you should notarise builds that you distribute to folks who need it. Remember that notarisation is (currently) checked as part of the Gatekeeper process. So, if you send a build to someone who installs the build via a Gatekeeper-checked channel, it’s reasonable to notarise it.

That definitely includes your customers. It also includes your external beta testers. As to your own internal QA folks, I think it’s reasonable to give them a way to get builds that doesn’t trigger Gatekeeper, and that avoids the need for notarisation.

Share and Enjoy

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

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

Thank you eskimo,


From your point of view this is reasonable, but we are a small team and have to be efficient. Automation is our goal, so we automatically build every hour (but only if code has changed) and upload the latest version to an internal web server. From there, the testers get the beta versions and should of course test notarized versions (own employees testing in daily use). So we immediately find out if something goes wrong. The external Beta testers having access to this folder, too. They test on demand. We do not have time to notarize manually if they want some new version. And if we release, we take the last build from this folder and upload it to some public location. Then we increase revision or minor version number for the next builds. Now, with notarization, this becomes more complicated. Even with nightly builds, the issue stays the same.


So, if not done automatically on build, we will have to notarize manually many times. Which is, from my point of view, no good solution because notarization needs up to 6 minutes and we build 3 applications.


Sadly, I do not really understand notarization in detail. The same for stapling it to the pkg file. I found no documentation explaining what "exactly" happens. For example, on what identifiers you store the notarization (hashcode of pkg file, BundleID, others?). And what means stapling this to the pkg file? Is it like signing? I would be happy if you can point me to some website where I can learn about this to better understand. Knowledge about this may answer my questions.


Thanks,


Kukulkan

Essentially, Notarization is just an antivirus check. But instead of having every Mac in the world constantly running antivirus scans of their entire hard drive constantly, Apple chose a more logical approach. Developers submit builds to Apple. Apple does the AV scan once. Then nobody else has to do an AV scan. I'm not sure of the exact logic behind the "ticket", but it is a convenient way to use an app's signature to verify that the app being checked is really the same app that Apple checked once before. I suspect it plays the same role as a hash value that traditional AV uses, but smarter. If you want to know more, check out these two (quasi-)URLs:

developer.apple.com/videos/play/wwdc2018/702/

developer.apple.com/videos/play/wwdc2019/703/


I suggest not worrying about the details that much. The key thing here is that Notarization is an Apple process. You don't need to test that. You only need to test your software. You can build and sign an app that would be identical to a notarized app in every way except for the ticket. All you would need to do is strip off the quarantine attribute:


xattr -r -d com.apple.quarantine /path/to/your/app


That would bypass Gatekeeper and your app wold run normally. Your app would still be signed and have the hardened runtime and any requirement entitlements, so you shouldn't have to worry about Apple's future plans to require signed apps. If you make any substantial changes to the app that would affect Notarization then you can always test that, if necessary.