Hacker News Reader

Comment by saagarjha | Hacker News Reader

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.

View on HN

Yes, which is why i wrote "you cannot run unsigned software" and the part about slippery slope.

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.

So, what follows next?

Hence the slope.

but who does this new step help?

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.

Why wouldn't a malware author just... do that?

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.

It's like sha256sum but cost $99 a year.

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.

That is what codesigning does.

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.

Checks are significantly relaxed after installation, so I don't think this would actually help here anyways.

Does it tie them to your Apple ID, or is it a key you can keep totally private from Apple?

It's not tied to a key at all, it's basically just a hash (read: the checksum kind) with no authenticity guarantees as to who signed the binary.

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 data science to find out who ran md5sum on their binary?

> 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.

https://developer.apple.com/documentation/xcode/notarizing_m...

There is no certificate involved in ad-hoc code signing. It's just a hash with no identity or chain of trust involved.

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."

https://developer.apple.com/documentation/xcode/notarizing_m...

https://developer.apple.com/library/archive/technotes/tn2206...

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?

No it doesn't. Apple ID is not involved in this at all. This is much ado about nothing.

Reply on news.ycombinator.com