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

I hope a well-informed person will clarify what exactly this means in practice.

I have to assume that it will still be possible to compile some code and run the executable without first passing it through Appleā€™s servers.




This is my understanding:

To notarize an app, you upload it to Apple. They'll run malware scans on it and such.

This only applies to people distributing apps outside the app store with the $100/year Developer ID certificate. If you're not signing your apps, I believe the behavior will be unchanged, because your app would already be blocked from running by default.

When you download an app from the internet using a browser or other quarantine-aware tool, it receives a "quarantine" bit and metadata recording the download URL. When you try to run the app for the first time, a window pops up saying "You got this app from shadywebsite.com, are you sure you want to open it?". Right now, the app's code signature is checked, and you get a message saying "this app can't be trusted" if the code signature check fails or the app isn't signed. Once notarization is required, signed apps that are not notarized will be prevented from launching in the same way as unsigned apps.

1. This will probably be a setting under "Allow apps downloaded from:" in System Preferences -> Security & Privacy you can revert if it breaks your workflow.

2. If the notarization check reuses the current mechanism, it will only apply to quarantined apps. If you're compiling something yourself, the compiler won't put a quarantine bit on it and it will execute fine. Same with homebrew/friends.


> 1. This will probably be a setting under "Allow apps downloaded from:" in System Preferences -> Security & Privacy you can revert if it breaks your workflow.

There's no longer a GUI option to allow unsigned apps by default. It was removed from System Preferences some versions ago.

But, you can do it via a one-line terminal command:

  sudo spctl --master-disable


I'm talking about the setting to disable requiring notarization for quarantined apps, which doesn't exist yet so I'm simply guessing it will show up there initially.


Without notarization, the signature of the app is tied to the lifetime of the developer id certificates. Thats one of the benefits of notarization (which Microsoft also I believe requires now) - the notary can say 'it was signed while the developer id certificate was still valid', which allows the signature to outlast the certificate.

I would expect Developer ID certificates to all expire by the changeover, with the only point for continuing to ship Developer ID certificates would be so that new app builds can work on pre-Mojave OS releases. Or I suppose skipping any Apple-run scans of your software.


Without notarization, you can still `codesign --timestamp` to have Apple co-sign your app, which validates that your certificate was valid when you signed the app, even if your certificate later expires.

Notarization is an advanced version of this where Apple adds to the signature "we have scanned the app for vulnerabilities and will continue to do so"


> Thats one of the benefits of notarization (which Microsoft also I believe requires now)

How does code signing work in Windows (for normal win32 programs)? I know I don't have any problems running 15 year old programs, which I have to assume predate any type of code signing.


I expect they won't be separate.


You can also allow unsigned apps on a case-by-case basis by right clicking the app and clicking "open"


FWIW, your compiler will not sign the code so notarization doesn't come into play at all.


This is a misleading statement. First, I personally do test Developer ID signed apps locally all the time. Notarization still doesn't come into play because there's no quarantine xattr to trigger Gatekeeper, not because they're signed/unsigned.


Unsigned apps cannot be notarized, and your compiler doesn't sign code (codesign does this unless you have an interesting compiler). In essence, there are two reasons why notarization doesn't have an effect here, the quarantine xattr and the fact that Apple will refuse to notarize an unsigned application; I was merely pointing out the additional, latter reason.


There is only one reason why the Gatekeeper notarization check does not trigger when you run code you compile yourself on-device: the lack of quarantine xattr. We don't need to exhaust the truth table to meaningfully describe the situation.

If you're going to be pedantic, you've reversed cause/effect by saying "notarization won't come into play because you can't notarize an unsigned app". You can still upload it to the notarization API if you like and watch it fail the tests, as this is a separate step from codesign. Whether you choose to do that has nothing to do with whether you've signed it.


My perspective was one where I compile software, codesign it, upload it to be notarized and then when it's downloaded the quarantine xattr gets set; if the code doesn't get signed none of the other steps make sense. But I'm pretty sure we both know how this works so I doubt arguing about the order or relevance of certain portions of the process is productive ;)


wonderful explanation, thank you!


macOS's current run preferences are:

1. Run only apps from the App Store

2. Run apps from the App Store or signed by a Developer ID

3. Run all apps (a hidden setting)

The default is 2 and you can achieve 3 (even when 2 is selected) by right-clicking and selecting Open on first-launch.

This change relates only to 2. "signed by a Developer ID" is being replaced by "signed and notarized by a Developer ID". This change applies immediately to developers who have never released a Developer ID app and will apply to all Developer ID apps in a future release of macOS.

From a user's perspective, this is a technical change that makes no difference. From a developer's perspective, it's a new, mandatory step in your deployment pipeline but otherwise not a major issue.


This only applies to apps signed using Developer ID.




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

Search: