Apple's new linker automatically adds an ad-hoc signature to ensure people building outside Xcode don't experience any disruptions as part of this new requirement.
This requirement does not change GateKeeper or Notarization.
More details here: https://eclecticlight.co/2019/07/09/understanding-signature-...
Yes, it's just an initial check. But is it necessary? What exactly is the use case basis for Apple transmitting and logging data on every application you run on an operating system you have a consumer guarantee of zero-tampering post-sale.
So, let's work this out: How easy is it to not upgrade macOS, retain consistent performance as usual, and not lose support if the userbase remains unsatisfied with Apple's change to an exchanged good? By my understanding, as with Windows 10, Apple will eventually require you to upgrade. If you're upgrading to a system that maintains the same performance and does not introduce express limitations to the product post-sale, that's great! Go for it, live merry. However, in this case, the userbase has zero clarification on both co-owned data transmission and a remote check that appears to trigger a constraint on workflow. There's no use case basis that makes sense for doing this, because Apple has established guarantees for decades prior to this new process that claim macOS is not susceptible to malware. So, it begs the question: Was Apple violating consumer protections by making false guarantees, or is Apple violating consumer protections by limiting the function and utility of the product post-sale?
That's what people are asking right now. We don't care about the nuance of the check. We care about the basic characteristics of, and more importantly the legitimacy of any use case for this check, given promises made to consumers at a prior time of purchase.
macOS is, in fact, susceptible to malware. (A notable example hit HN just the other day [1].) I don't think Apple has ever literally claimed that it isn't susceptible, though they may have sort of hinted at it (especially at the height of the "Get a Mac" campaign). To be fair, there has not been very much macOS malware then or now, though it's questionable how much that has to do with macOS's design as opposed to factors like the size of the target userbase.
The broader point though, is that Apple has established the belief that macOS is not susceptible to malware. That's why people don't "need" a virus scanner running in the background.
And this belief is widespread enough that it warrants questioning the basis of a use case for this check: Why does macOS need to send my data to a remote server upon initial load of each application to verify it with Apple's whitelist (approve-list? what's the right term these days?), if the operating system's existing protection has to date fulfilled the implied guarantee by CEO, Tim Cook, and former CEO, Steve Jobs, of zero or limited, but otherwise insignificant, exposure risk to malware?
When a piece of (signed) malware becomes even moderately sucesful, Apple shuts down all its installation vectors by banning every dev account that's ever signed it. If nothing else this makes it harder to develop malware that spreads rapidly through the App store, forcing bad actors to invest a lot more work into finding 0-days.
Also so the os doesn't have to repeatedly rescan apps, etc.
All major Linux distros for example still have no viable way of creating signed programs or anything like Gatekeeper.
So, what follows next?
Hence the slope.
https://developer.apple.com/documentation/xcode/notarizing_m...
> You can only notarize apps that you sign with a Developer ID certificate. If you use any other certificate — like a Mac App Distribution certificate, or a self-signed certificate — notarization fails with the following message: "The binary is not signed with a valid Developer ID certificate."
https://developer.apple.com/documentation/xcode/notarizing_m...
https://developer.apple.com/library/archive/technotes/tn2206...