Hacker News new | past | comments | ask | show | jobs | submit login

And, not mentioned in the article... you have to have an Apple Developer ID which costs £79/year ($99). Presumably if your subscription lapses any previously released software will stop working?

That is the part I find most offensive, if it was just difficult and buggy I would suck it up and work around it. But having to pay for the privilege is too painful, particularly if you're offering free software.

For my case (non GUI app) I can at least distribute via Homebrew and have the user build from source in a more or less automated way.

Another notarization helper tool is here https://github.com/mitchellh/gon




No, if your subscription lapses previously released software won't stop working. If you are offering free software you can sign with an ad-hoc certificate, and instruct the user on how to bypass gatekeeper, which isn't great at all but it doesn't cost any $$.


Looks like this explains how: https://www.digicert.com/kb/code-signing/mac-os-codesign-too... but... "only Apple Developer code signing certificates are compatible with GateKeeper"

Does code-signing with an ad hoc certificate and no notarization provide any better experience than just unsigned code?

Do you get a friendlier message (c/f "malicious software: Move to Trash") when Gatekeeper blocks it?


Unsigned (arm64) binaries don't run at all on M1 Macs, so yes, an ad-hoc certificate provides a better experience ;)


I just tried an unsigned bin on M1 Big Sur and the experience is the same:

it's initially blocked with a "Move to Trash" dialog

but you can go to security prefs and click "allow anyway"

Then try again, click "open" rather than "move to trash" on another warning dialog and the file does get run.

I haven't tried a signed+un-notarized one but it sounds like it'd be similar?


I suspect that the code you're trying to run is ad-hoc signed.


Not by me... and it's my own code build from src in a github action.


When targeting ARM macOS, the linker automatically ad-hoc signs everything it outputs. You can check this by running `codesign -dvv` on the binary. Alternately, if your binary is an Intel binary running under Rosetta, those can be unsigned.


Hmm, it was built on Intel though (GitHub Actions macos runners are only Intel)

But maybe some other part of the toolchain (Gradle, GraalVM native-image) was implicitly ad-hoc signing it


https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-...

"This new policy doesn’t apply to translated x86 binaries running under Rosetta"

...I guess that's why.

The whole situation is so confusing. The article talks about how unsigned code won't run on ARM macs, but an ad hoc cert is fine.

I suppose this fits what others have said in the thread - unsigned native-ARM binaries will be completely blocked. Unsigned x86 binaries can run on ARM macs under Rosetta (what I tried... or possibly my bin was signed by the build tool).

But all these will still get block/warnings from Gatekeeper if un-notarized, which is the part you have to pay for.

This https://github.com/Homebrew/homebrew-core/issues/47129 suggests there is yet another factor to consider - the "quarantine" flag. Presumably downloading a tar.gz from github releases via Chrome gets a quarantine flag triggering the Gatekeeper warnings. That Homebrew issue (from 2019 though...) seems to say that "bottles" installed via Homebrew (which is basically the same thing - a precompiled bin downloaded from internet) won't have the quarantine flag set and they just need to be ad-hoc code-signed.


Instructing users on how to bypass gatekeeper is a nonstarter, as explained here:

https://lapcatsoftware.com/articles/unsigned.html

This simply is not a viable distribution method for the mass market. Apple has positioned apps from devs that pay Apple so far above apps from devs that don't that you cannot compete outside of their subscription revenue model.


[flagged]


In this case I think it is accurate given forum post evidence, but possibly dated to 2019 given other dates on the page and the fact that Big Sur is not mentioned.


This puts it well, albeit with (enjoyable) snark.

So often these criticisms read like it’s expected that Apple conform to the Linux “model” of doing things, and anything else is like the plague.


Code signing isn’t linked to an active developer subscription, if it lapses all existing signatures are still valid - you just can’t sign more.


What happens when the cert root expires? Does it not expire or does Apple grant an eternal valid signature when apps were signed before the root expired?


For apps I’ve downloaded on my iPhone, there are sometimes updates that denote Apple updated the key. Assuming that’s App Store only behavior though.


Apple just did this recently for iOS 14.5, actually.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: