6 ms·

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

tambourine_man 8y ago
“…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
- sjwright 8y ago
  I wonder, will that include random terminal apps like gnu grep, and if so, how will the notary be attached?
  - saagarjha 8y ago
    They can be distributed without a signature.
    - tylerhou 8y ago
      But the post says "all software." Surely that implies that macOS won't let unnotarized software run?
      - saagarjha 8y ago
        That software will not have the quarantine bit set, so I don't think these restrictions will apply.
- dwaite 8y ago
  We had a pretty definitive answer last WWDC during the session on notarizing. https://developer.apple.com/videos/play/wwdc2018/702/ 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.
pvg 8y ago
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.
- floatingatoll 8y ago
  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.
  - deleted 8y ago
    [deleted]

tambourine_man 8y ago

“…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

sjwright 8y ago
I wonder, will that include random terminal apps like gnu grep, and if so, how will the notary be attached?
- saagarjha 8y ago
  They can be distributed without a signature.
  - tylerhou 8y ago
    But the post says "all software." Surely that implies that macOS won't let unnotarized software run?
    - saagarjha 8y ago
      That software will not have the quarantine bit set, so I don't think these restrictions will apply.
dwaite 8y ago
We had a pretty definitive answer last WWDC during the session on notarizing. https://developer.apple.com/videos/play/wwdc2018/702/ 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.

pvg 8y ago

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.

floatingatoll 8y ago
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.
- deleted 8y ago
  [deleted]