Hacker News new | ask | show | jobs
by supermatt 2129 days ago
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.

1 comments

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

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.

> You CANNOT bypass gatekeeper on silicon - that is the whole point, otherwise there would be no diffference!

Yes, you can. The only difference between Intel and Apple silicon in this regard is that binaries that literally have no code signature (as opposed to a self-signed one) will not run. It's a technical cleanup measure that removes a special case (executable with no associated signature blob), not a lockdown measure. It's not intended to make a difference from the user's point of view.

So its just the format of the executable that has changed? This certainly isn't what was discussed the other day - and seemingly confirmed by a user with a transition kit... :/

I see why you mentioned ELF, now.

Ill descend from my soapbox on that matter, then. Thank you for correcting me. :D