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

TLDR highlights:

Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.

Apple recommends that you notarize all of the software that you’ve distributed, including older releases, and even software that doesn’t meet all of these requirements or that is unsigned.




So the actual title should be "In a future version of macOS, apps signed with Developer ID will require notarization by default".


“…for all software.”

It’s very vague as usual.

I guess the current work arounds will still apply (right click open, for instance)

But we'll probably have to wait for WWDC for a definitive answer


I wonder, will that include random terminal apps like gnu grep, and if so, how will the notary be attached?


They can be distributed without a signature.


But the post says "all software." Surely that implies that macOS won't let unnotarized software run?


That software will not have the quarantine bit set, so I don't think these restrictions will apply.


We had a pretty definitive answer last WWDC during the session on notarizing. https://developer.apple.com/videos/play/wwdc2018/702/

Developer ID signing will eventually be replaced with notarized Developer ID signing, on some suitably long roadmap that can be assumed to first involve a change in new app signing, then developer warnings of impending change of default on new OS version, that new OS version having user visible warnings, finally having the old developer id signatures ignored (making apps behave as unsigned, requiring the same right-click opening/exempting as today)

For those who are looking for my entry into the pool - the OS changeover for user-visible warnings will be this time next year, with it made obvious (at WWDC 2020) that the September 2020 macOS major release will make the final change to ignore old non-notarized signatures.


The actual title should be the title of the article, which is neither misleading, nor clickbait. The made-up title is both of these things.


The linked document, as of when I wrote that anyways, was not a news article at all. It was a developer support document that someone was linking as the primary - and, at that time, only - source of an Apple policy change. Using the original KB link’s title would have pointlessly obscured the relevance of the link to HN readers.




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

Search: