Notarization and enhanced runtime implications

Hello,


I have several questions about notarization and enhanced runtime and their behavior in certain scenarios:


1. We install our SW via notarized .pkg. We upload every .pkg to notarization, so Apple sees all the binaries inside the app bundle. But old installations are updated by patching individual files. The signature will remain valid, but the new binaries did not enter the system via any notarized .pkg. Will this continue to work? It saves a lot of bandwidth to download only small diffs.


2. Our SW is an Avast Antivirus solution. Part of it is a scanning engine libraries + virus definitions. These are distributed separately and updated 4 times per-day to react to latest malware. The engine libraries are properly signed but not notarized as they are not contained in any bundle that is supported by notarization. Enhanced runtime docs mentions that app can load libraries signed by the same developer, so I expect our notarized app to be able to load non-notarized libraries signed by us. Is this correct? Will it continue to work?


3. We are distributing our SW as a .pkg inside a .dmg. We have our own stapler service to staple the .dmg with user-specific data (licenses). We are doing this from our web-pages when user buys our product, so we need it to be lightning fast. Will the new gatekeeper allow user to install a notarized .pkg from a non-notarized .dmg?


4. During our first attempts to make notarization work, we had received some "Bad library" errors trying to load libraries build agaisnt 10.6 SDK. But we could not find any detailed violation description in any log files in the Console.app. Where are such violations logged to? Iit would really help us understand the cause of the issues.


Thanks for any relevant comments.


Jakub

Replies

4. During our first attempts to make notarization work, we had received some "Bad library" errors trying to load libraries build agaisnt 10.6 SDK.

That’s not going to work. Notarisation requires the hardened runtime, the hardened runtime requires library validation, and library validation requires that you link with (at least) the 10.9 SDK.

For any give Mach-O image, you can get the SDK used with the following command:

$ otool -l /path/to/your.dylib | grep -B 1 -A 3 LC_VERSION_MIN
Load command 9
     cmd LC_VERSION_MIN_MACOSX
 cmdsize 16
 version 10.11
     sdk 10.14

You should run that command over all the Mach-O images in your product to make sure they report (at least) the 10.9 SDK.

Share and Enjoy

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

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

1. Any (more or less) modification of existing files in a signed bundle will invalidate the signature for that bundle. That will not be a problem for now as these files have either already been accepted by Gatekeeper or your downloading process has bypassed Gatekeeper. However, you are using a highly customized process here. Apple is not going to be testing your distribution process. You are at significat risk of breakage in the future. By invalidating your signatures, your app is also at risk of exploitation by malware and software pirates. Bandwidth is not an issue to be concerned about.


2. You would have to ask Avast about. In my experience, I have found antivirus vendors to be remarkably slow to notice significant changes to Apple's operating systems, even with Apple's massive hype machine advertising them or direct e-mails months in advance. And these are the people who are supposed to protect us against zero-day threats? By the way, isn't Avast the one that installs that man-in-the-middle SSL hack?


3. I strongly encourage you to review those practices. I anticipate massive problems for you in the future.


4. If 10.6 is such a massive revenue source for you to continue to support it, then whatever pre-notarization processes you have should continue to work unchanged. But to support modern systems, you can safely drop support for anything before 10.11 without anyone noticing. Few people even run anything before 10.13 anymore.

1. It does not break the apps signature as we patch the signature files as well. After the update, the application is correctly signed. I personally don't like to re-download the entire application any time there is a minor update. How many times was I disapointed that I can't install a new version of app to my iPhone without Wi-Fi cause it was over 100MB although there were just minor changes.


2. I work for Avast so I have the insights. I am asking someone from Apple, to provide documentation on how the enhanced runtime and notarization actually work together. When does the gatekeeper come into play? When is the notarization stamp checked? Does the system hold the notarization info somewhere in the system after the package was installed or is it just attached to the .pkg/.dmg and used during installation and then never again? There is documentation on how to notarize things, but the interactions during the apps lifetime are not properly documented. Maybe I just wasn't able to find it. Right now it seems, that a notarized application can load a library that has not been notarized but is signed by the same developer. This is in complience with the TechTalk on WWDC 2018. I want to make sure that this will continue to work in the upcomming version of macOS. Notarization process is said to take "up to an hour" and delaying an antivirus definitions update for an hour might be a long time when there is a new aggressive virus we need to catch.


For your claim that AV companies are slow to react to Apple changes. It is because we support our users also on 10.9 systems with program updates and 10.6 systems with virus definitions. We need to be able to work/debug on these systems as well. It is about 10% of our userbase. They are not "source of revenue" as you called it, but we do our job primarily for the people and their online safety. The status of development tools does not help us here. Xcode 10 does not allow us to build Swift 3 code and Swift 4 aware Xcode can't be installed on older systems. That makes it impossible to transition to latest Xcodes + SDKs + Swift as it would be very difficult/impossible to debug any issues on older versions of OS without the tools. Furthermore, most new features Apple introduces are not properly documented. There is a documentation for some simple use cases, but for really complex SW it takes a lot of experimenting to figure out how things realy work together and we are never sure, whether it will not change with newer versions of macOS. Thats why we tend to stick to things that have been working for a long time and seem to be stable.


FYI we were wondering why some users stay on older systems, and most of the times it is because they are using some software, that is no longer working on the newer versions of macOS, but they want to keep using it.


3. Since the notarization was introduced, I was trying to talk to guys in Apple to explain our use case and figure out, what is the correct replacement in case this will stop working. I doubt we are the only company that is providing customized installers to their users. It really simplifies and improves user experience and that is something Apple always had in mind. If the only way will be to re-notarize the dmg, we will have no other option then to spam notarization servers with thousands of notirazation requests with the same binaries but slightly different data inside a .dmg. I do not see any point in doing that. The .pkg is notarized and unchanged and all executable code is inside the .pkg. All we are changing is some textual data inside the .dmg. If there is a plan to disable this option, please reconsider it or design and describe a flow that would allow installer customization.


Best regards,


Jakub

Sorry, but I didn't see your response until just now.


1) Hacking up the signature files seems to be just asking Apple to break your app. If you are doing something funky, you can get away with it by aggressively testing your software in every minor OS update while still in beta. However, the last release often isn't included in the beta, so there is always a risk of being surprised. Furthermore, Notarization is an interaction with Apple's corporate servers above and beyond OS updates. What you are describing is just living dangerously.


2) Being slow to react to Apple changes has nothing to do with supporting a legacy user base. What I am talking about is when Apple announces some big change and then AV vendors ignore it for months until something breaks. Oh, wait...that is exactly what is happening here, isn't it? To make matters worse, Notarization is (going to be) a requirement. Swift might be required one day in the future, but it is purely optional at this point.


3) If all you are changing is some text data, then why not download that as needed? Otherwise, it sounds like you are talking to Apple. I'm not Apple. Eskimo is Apple, but you can't count on him showing up. If you have concerns and need direct Apple assistance, use a DTS ticket instead of posting in the developer support forum.

3) I totally see your point: Apple does not explain what you can do with an app after it has been notarized, neither do they explain the actual results of notarization during installation or other scenarios where it might make a difference. This is highly intransparent and people/companies have to make expensive guesses as toward what should be done.

You can do anything you want to your app. But if you somehow invalidate the signature or the notarization, then it isn't going to work. You can write random data into the executable too. The app won't launch after that. Is that a problem?


Apple's security infrastructure is, by nature, always going to be evolving. Apple isn't going to give you many details. Apple probably doesn't know all of the details themselves. They have to see how the security landscape evolves over time. I'm sure Notarization is going to evolve with it.


Guesses are always free. It is labour that is expensive. If you are doing risky work based on incomplete information, then you can expect that to be an expensive exercise. You can mitigate the costs by making design decisions that are less risky.