[supermatt]

Arbitrary code, not binaries. You can run arbitrary code through a compiler (which gets signed automatically when it gets linked) and then run it, or you can run arbitrary code through an (already signed) interpreter.

You CANNOT run an unsigned binary on silicon, but I totally understand your confusion given their statement.

Edit: To clarify further, you cant run an ARM binary - x86 apps going through rosetta (currently) work as they used to (right click and you can open).

[comex]

Why do you care about unsigned binaries when self-signed binaries work fine and the linker produces signatures automatically? It's just a technical change in the required format for executables, not a substantive change in what you're able to do. You may as well complain that macOS doesn't support ELF binaries.

[supermatt]

Not self signed. Signed by an Apple issued cert. This entire thread is about control of distribution. You absolutely will not be able to distribute a Mac app without an Apple dev subscription in order to have your app notarised, agreeing to everything that comes with that. At the moment you can. This is clearly a “substantive change”.

I am a proponent for code-signing, I just don't see why I cant use my own cert (such as that issued for a domain name) instead of an apple issued one - if it is solely about preventing code tampering, as they state...

The actual reason behind a central issuance of certs is DRM. If apps NEED to run through this gatekeeper, then the gatekeeper can phone home to get a license for you to run the app (or not). This will enable the revocation of a cert for distribution of malware, but will also enable revocation for other reasons - like a dev breaching the terms of their agreement with apple (whatever those may be).

That is what the issue is. There is literally no benefit in this unless apple can revoke certs, because there is nothing to stop a dev signing a malicious app!

I don’t see what this has to do with elf binaries. I mentioned arm binaries because that is what all upcoming apple “computers” will be.

[comex]

That's not correct. To quote Apple:

> New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature issued locally is sufficient, which includes signatures which are now generated automatically by the linker.

An "ad-hoc signature" is Apple jargon for a code signature without a certificate (so really just a set of hashes, no actual public-key signature); I called it self-signed since it's a more familiar term. By "there isn't a specific identity requirement" they mean it's not required to be Apple-signed.

Of course, macOS on Apple silicon will still require an Apple signature by default like it does on Intel, but you'll be able to disable that like you can on Intel.

[supermatt]

And, as a user, what is the mechanism for ad-hoc signing an unsigned binary on silicon? :)

You can’t distribute ad-hoc signed binaries. You can’t disable/bypass the gatekeeper on silicon.

If you have access to a transition kit you can see this for yourself.

[comex]

> And, as a user, what is the mechanism for ad-hoc signing an unsigned binary on silicon? :)

`codesign -s - my_binary`, though that would rarely be necessary unless you patched it in a hex editor or something, since otherwise it would have been automatically ad-hoc signed when it was linked.

> You can’t distribute ad-hoc signed binaries.

They have the same distribution restrictions on Apple silicon as on Intel. You can, but it requires the person running the binary to either (a) run it in a terminal, (b) right-click Open, or (c) use spctl --master-disable to disable Gatekeeper entirely.

[supermatt]

Good luck expecting a user to do that! As I already said, you cant distribute an ad-hoc app, so this is exactly what they would have to do - hence my smiley face!

You CANNOT bypass gatekeeper on silicon - that is the whole point - otherwise there is no difference to the current behaviour.