What I don't understand is that if any of these problems are present in an app bundle, why does Apple's notary service still report success and allow me to staple a ticket to the app?
Because it is likely a runtime failure. You didn't notice because you were running in whatever development environment that Qt provides. But Gatekeeper does additional runtime dylib checks.
Unfortunately it also doesn't tell me anything about why it's failing to allow my app to run!
Have you looked in Console? One of the times I responded to a question virtually identical to yours, I found a dylib loading problem that was causing notarization to fail. There aren't any easy-to-use error messages for this because it only affects people who aren't using Xcode. Xcode just works. But if you choose to roll your own, you have to be willing to debug the errors on your own too.
I have been using this since, at up until now, it had been working fine.
This is what I mean when I say, "you'll get it to work today, but it will be broken again next month."
Is the alternative you recommend to individually sign all bundles, executables and dylibs from deepest to shallowest in the bundle?
The "alternative" is to use Xcode which does it all correctly. Failing that, you could look to see how any other app using Xcode is built and copy that.
However I had no problem getting it notarized and running in macOS 10.15 until now.
See my note above.
Very little of consequence has changed between my prior and current attempts!
There have been tons of changes. In my previous message, I said, "there is an entire industry dedicated to breaking Apple's security." I wasn't joking. This is how it works. Apple has to patch these bugs or their authors will release them. It is legalized extortion. This is where you see the ramifications. One of those exploits used the same slightly lax dylib loading scheme that you depended on. That bug is now fixed, so your app is broken.
Is @rpath still allowed?
@rpath is the preferred method. However @rpath is dynamic. Qt libraries, especially if you build them yourself, may have funky rpath values that specifically cause this problem.
And more importantly, I've yet to see any compelling explanation why this entire notarization system works better than, say, some kind of client-side process that scans executables to try and detect malicious code the first time it's executed. That's been a successful method of stopping malware on every other operating system.
Well, no. In fact is has been the opposite. Apple's security platform has been more successful than any client-side approach. And it certainly provides a better user experience.
And don't forget that I also mentioned fraud. Malware is what everyone is scared of and is what drives the Apple security and clickbait industry. But it is largely just fearmongering. Apple's security infrastructure works very well and there is very little risk. Nobody talks about fraud. Fraud is orders of magnitude bigger than malware. Most of these "security exploits" are also useful for fraud. But in this case, it is developers being defrauded. My piracy rate is around 20% for direct sales. (Mac App Store appears to be 0%.) And I do a lot of DRM. It is a free app, with in-app purchase. But in order to run the pirated version, you have to disable Apple security. I'm nobody. I can't imagine how bad it is for big developers.
- Malware definitions can be updated frequently. If a novel piece of malware manages to slip through Apple's notarization checks and is notarized, it'll still appear to be legitimate, whereas as-needed scanner could detect it once the malware definitions are updated.
It doesn't work that way. Apple has multiple levels of security. For all practical purposes, users have to install malware themselves by overriding Apple security.
- It avoids all of the aggravating and frustrating work developers have had to go through getting their software notarized
Notarization is fall-off-a-log easy, for everyone who uses Xcode, properly signs, and avoids problematic frameworks.
- It provides a better user experience because it provides just as much protection while still allowing more apps to run.
Nope.
- It allows the platform to remain more open.
Wrong platform, Corrigan. That doesn't matter here.
