To be clear, this just means all binaries need codesign --sign - run on them before they will run. You don't need to pay to do this, so it's a minor annoyance rather than Apple centralizing control of app distribution.
That's exactly what I'm confused about, where is the slippery slope? It's an extra step in your build process–an annoyance, not a slope. It's like if there was a requirement that macOS would not run binaries unless you stuck "APPLEISCOOL" at the front of all your binaries.
The slippery slope is at the point where a few years ago you could run any application you wanted, then you started getting some scary messages for unsigned applications but still could run applications, then you had to work around the scary messages and now you cannot run unsigned applications.
As far as I understand, there are (surprisingly many) different code paths in the operating system based on whether a binary is signed or not and I would guess that Apple no longer wants to keep around the one where unsigned binaries are a thing.
I believe one of the main security benefits of these requirements are ensuring a binary hasn't been altered maliciously, or otherwise I guess. Not preventing outright malicious applications.
Also so the os doesn't have to repeatedly rescan apps, etc.
sha256sum generates a sum, you still need to store that sum somewhere that isn't controlled by the malware creator or they can just change the sum too.
All major Linux distros for example still have no viable way of creating signed programs or anything like Gatekeeper.
Malware authors frequently sign their applications with valid Developer ID certificates. This change is not something that would keep them out and I strongly suspect that was not the goal when it was made.
The key here is that Apple can also remove and retroactively revoke signatures on signed applications, which is why you rarely see Mac malware stick around after it makes the headlines these days.
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.
If you have a vulnerable app, it might modify another already approved app that is already installed, thus omitting the scary message about untrusted code before being run.
To the average user, yes, but Apple can see the chain of trust and can do the data science required to figure out who signed what. You better believe that in the even of a large scale malware distribution via signed binaries, they're going to be revoking those certs and tracking down the accounts responsible (like after the VLC website hack).
> The notary service maintains an audit trail of the software distributed using your signing key. If you discover unauthorized versions of your software, you can work with Apple to revoke the tickets associated with those versions.
Yes but "ad-hoc" code signing is almost useless on its own on macOS, it almost always goes with notarization, which does require a revokable certificate with a chain of trust attached to a Developer ID for the initial code sign.
> 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."
Out of curiosity, what's the point then? Why not just phone home with the hash of the binary, instead of forcing developers to assign a UUID/pseudohash to their binary?
