Apple's "notarisation" – blocking software freedom of developers and users
fsfe.org296 points by DavideNL 3 days ago
296 points by DavideNL 3 days ago
I stopped releasing binaries for a number of my tools because I didn't want to pay the $100 a year for the right to do so, and I got tired of explaining how to run them without signing.
The post I wrote to point people at anyway:
Note that the submitted article is about iOS, not macOS. The "notarization" process on iOS shares practically nothing with macOS except the name:
https://developer.apple.com/help/app-store-connect/managing-...
iOS notarization is just app review with fewer rules.
Doesn't it also require the same $100 annual fee?
Yes, the Apple developer program is $99 per year, but again, this has nothing to do with the submitted article.
You can bet that Apple will pervert macOS notarization for app review just as soon as they can get away with it.
> just as soon as they can get away with it
Who is stopping them currently?
Developers would revolt if Apple introduced it right away. The steps will have to be gradual. But it’s pretty clear that the open, Unix-based Mac is an odd duck in Apple’s current lineup — and Apple is a company that likes to homogenize.
> Developers would revolt if Apple introduced it right away.
What does "revolt" mean, exactly? I'm a developer myself, so I'd like to know what I would/should be doing?
Keep in mind that a lot of Mac developers have iOS apps too, so they're accustomed to app review.
> The steps will have to be gradual.
Developer ID was introduced in 2012, and notarization was added in 2019. What are the next steps, and what is the timeline for them?
easier to release the source code here and better for your customers right?
The same thing exists on Windows, developers have to code sign their binaries. It's even worse in my experience because you have to use a token (usb key with cryptographic signing keys in it) and that's impractical if you want your ci/cd to run in a datacenter. At my company we had a mac mini with a windows VM and a code signing token plugged in just for the purpose of signing our macos and windows binaries.
Another solution that is not mentioned in the article is that users of both macos and windows should be able to easily integrate the certificate of a third-party editor, with a process integrated in their OS explaining the risks, but also making it a process that can be understood and trusted, so that editors can self-sign their own binaries at no cost without needing the approval of the OS editor. Such a tool should ideally be integrated in the OS, but ultimately it could also be provided by a trusted third-party.
I struggled with a similar problem recently. You can use osslsigncode to sign Windows binaries from Linux. It is also possible, with some pissing about, to get everything to work hands off.
In the end we went with Digicert Keylocker to handle the signing, using their CLI tool which we can run on Linux. For our product we generate binaries on the fly when requested and then sign them, and it's all done automatically.
> The same thing exists on Windows, developers have to code sign their binaries.
> Another solution that is not mentioned in the article is that users of both macos and windows
The article is actually about notarization on iOS, which is vastly different from notarization on macOS. On iOS, every app, whether in the App Store or outside the App Store, goes through manual Apple review. But apps distributed outside the App Store have fewer rules.
If I try and run an unsigned program, the UAC window will be yellow, but I can run it with zero issue.
I cannot do the same thing on MacOS with the same ease, and that's the issue.
Yes I don't understand what he means. On Windows you can basically tone down the security to the point you basically tell it to shut up and let you do anything you want, including shooting yourself in the foot (which is fine by me).
On macOS you have to resolved to various tricks to be able to run stuff you have decided you want to run, for whatever reason.
Just FYI, you don’t have to use a USB stick, you can also use HSM like azure key vault and sign using azure signtool.
Azure Key Vault - even in the ‘premium’ HSM flavour can’t actually prove the HSM exists or is used, which doesn’t satisfy the requirements the CA has. In theory, it shouldn’t work - but some CAs choose to ignore the letter and the spirit of the rules. Even Azure’s $2400a month managed HSM isn’t acceptable, as they don’t run them in FIPS mode.
Nope. Notarization is not code signing. It’s an extra step, after code signing, where you upload your software to Apple’s servers and wait for their system to approve it. It’s more onerous than code signing alone and, with hindsight, doesn’t seem to have been offering any extra protection.
It's not the same, but in practice it's also not so different. Microsoft keeps track of how many times a certain executable has been run and only after a certain threshold does the executable become openable without hunting for tiny buttons. The kicker: this also applies for signed binaries.
Microsoft will upload these executables to the cloud by default if you use their antivirus engine ("sample collection").
In a way, Microsoft is building the same "notarisarion database", but it's doing so after executables have been released rather than before it. Many vendors and developers will likely add their executables to that "database" by simply running it on a test system.
On the other hand, SmartScreen can be disabled pretty easily, whereas macOS doesn't offer a button to disable notarisarion.
Microsoft's notorisation sounds fully automated and transparent, while Apple's is more political and hands on. Individual apps getting their notorisation slowed down to a glacier pace because the platform owner doesn't like them doesn't seem to happen in Microsoft land.
Wasn't there even a story some time ago about how some completely legit, legal, above-board app to virtualize old (pre OS X) versions of Mac OS got rejected by Apple's notarization process?
Yes. Probably this story ?
https://9to5mac.com/2024/06/19/iphone-pc-emulator-block-ille...
“UTM SE” is now on the App Store. Perhaps this was just a mistake?
https://apps.apple.com/us/app/utm-se-retro-pc-emulator/id156...
It was the standard business pattern of denying your competitors everything you can, unless it causes a third-party fuss.
I'm honestly not even sure it's about denying competitors anything. It feels more like denying their users. Apple has a long history of intently denying users the ability to do what they want LONG before any potential App Store competitors appeared.
Note this is an iPhone app (noting because this thread seems to mainly be about macOS).
Notarization is the same for macOS and iOS AFAIK. Both platforms have a separate app store review process that's even more strict than the notarization process.
> Notarization is the same for macOS and iOS AFAIK.
Assuming the basic facts are straight, the the linked story explicitly proves this is false:
> UTM says Apple refused to notarize the app because of the violation of rule 4.7, as that is included in Notarization Review Guidelines. However, the App Review Guidelines page disagrees. It does not annotate rule 4.7 as being part of the Notarization Review Guidelines. Indeed, if you select the “Show Notarization Review Guidelines Only” toggle, rule 4.7 is greyed out as not being applicable.
Rule 4.7 is App Review Guidelines for iOS, so this would be a case of failing notarization for iOS App Review Guidelines, which means the policies (and implementation) are different between platforms.
(Of course there's no such thing as "Notarization Review Guidelines" so maybe this whole story is suspect, but rule 4.7 is the App Review Guidelines rule that prohibits emulators.)