13 ms·

Here's how I'm understanding this: Currently, you have three options to distribute software on macOS. 1) You register as an Apple Developer (which costs $100

Here's how I'm understanding this: Currently, you have three options to distribute software on macOS. 1) You register as an Apple Developer (which costs $100 a year) and distribute through the Mac App Store, where Apple will do their review/automated scans/whatever, resign the app with their certificate, and then distribute it. 2) You register as an Apple Developer but don't distribute through the app store, and instead sign your software with the certificate you get through the developer program. It looks like, starting in macOS 10.14.5, you'll have to upload your software to Apple to be "notarized" if you want to distribute this way. It sounds like it's only for new software at first, but eventually old software will stop working unless it's notarized. 3) You don't register as an Apple Developer, and you just build and distribute software however you like. Currently, if a user tries to run your software it simply won't run, and the user has to know to go into system settings and manually give it permission. What isn't clear (at least to me) is weather this option will remain unchanged. This sentence: > In a future version of macOS, notarization will be required by default for all software. kind of makes it sound like like all software will have to be notarized, which implies that you have to be an Apple Developer to distribute at all. But saying "by default" makes it seem like there's some kind of option given to the user, so maybe it just means that software that's distributed by a registered Apple Developer but isn't notarized just moves down into the third tier of software that has to be explicitly allowed to run by the user. It seems like Apple's ideal model is that if a user wants to run software of any kind, it has to go through them (like iOS). I don't think that's what they're announcing for macOS, but it's a little hard to say for sure.

Wevah 8y ago
My understanding is that if you’ve released Developer ID-signed software in the past, you won’t have to notarize just yet.
RHSeeger 8y ago
How does it work if you want to write your own software and run it locally on your machine?
- opportune 8y ago
  You just chmod it, in my experience. Not sure what happens if you need to really install something on your own machine
- month13 8y ago
  I'd imagine it's another tier for Gatekeeper (the mechanism in macOS that verifies this). Gatekeeper can be outright disabled if desired (appears missing from the System Preferences UI though), allowing all unsigned code to run. Currently, if an app isn't signed and you have Gatekeeper set to "Allow apps downloaded from App Store and Identified Developers", you'll get a prompt stating it isn't permitted to run. If you open it using the context menu, you'll get a button in that prompt to "Run Anyway". Alternatively, recently blocked apps by Gatekeeper appear in System Preferences allowing for manual override as well. I'd imaging the notary service would be included in the "App Store and Identified Developers" section, and the same restrictions apply. As for your own software, XCode signs it with your Apple ID automatically. Everything else, via terminal is the same as always.
- captaincrowbar 8y ago
  There's no interaction with Gatekeeper there. An executable you've built yourself will just run normally (assuming it has the x attribute of course). OK, quick lesson in how Gatekeeper works: When you download a Mac app from the web, or save it from an email, a bit of metadata called the "quarantine attribute" is attached to it. When you try to run an app with the QA, Gatekeeper checks whether it's allowed to run; by default this will be allowed if it's signed. If it doesn't pass GK, you can still run it anyway by right-clicking on it and choosing "Open". When the app runs, regardless of whether GK passed it or you overrode GK, the QA is removed. After that GK no longer cares about it, and the app will just run normally without further fuss. Safari and Apple Mail automatically add the QA to anything they download, and most 3rd party browsers and email clients now do the same. But if you download an app using most command line tools (curl, wget, ftp, scp, etc), or if you build it yourself from source, then the QA never gets attached to it in the first place, so GK doesn't care about it and the app just runs normally. As far as I can tell the new notarization system doesn't change any of this, it just adds another form of code signing.
opportune 8y ago
If they get rid of option 3, they will make macs unsuitable for a lot of development outside of the Apple ecosystem (they must still be good for development for iOS and macOS apps). Surely that is a large enough part of their userbase that they won't just throw that away
- tambourine_man 8y ago
  >Surely that is a large enough part of their userbase that they won't just throw that away Don’t be so sure. It’s truly impossible to predict and understand some of decisions Apple's made in the pro market. Best one can hope for is to get an explanation 10 years from now in a podcast or blog post. If there’s still such a thing
  - inlined 8y ago
    Surely you can turn on option 3 indefinitely for local builds at least. Otherwise Apple kills the ability to develop any software while offline or behind a firewall.
    - jakobegger 8y ago
      Gatekeeper only applies to software downloaded from the internet. Browsers set the "quarantine" attribute for downloaded files, and then Gatekeeper kicks in on first launch. Software that you build locally, or that you install with a package manager, is not affected. The goal of Gatekeeper is to keep your Mac safe -- not to control what you can do on your Mac.
      - puzzledobserver 8y ago
        Would something like "cat a.out > b.out" bypass Gatekeeper? I am always puzzled by apps which know the origins of files that they open.
        true_religion 8y ago
willio58 8y ago
As a life long Mac user, if option 3 is removed i will be leaving for Linux.
- mark_l_watson 8y ago
  Yup. I have a MacBook and a really nice Linux laptop. While I work a little faster in the Mac, it feels good running Linux. I don’t think I would be OK with option 3 - agree with you. EDIT: I am fine with a sandbox for iOS, not macOS.
  - teamspirit 8y ago
    This is why I still haven't bought a tablet. I was really excited to get the latest iPad with the A12 bionic, then I started looking into open source software (only really need two: password store and ssh) and realized it essentially doesn't exist. And with the current state of Android tablets, I guess I just won't be getting one for a while.
    - saagarjha 8y ago
      There are plenty of SSH and password management apps on iOS. Did they not work for you?
      - kbenson 8y ago
        Open Source is what he said doesn't exist. I'm not sure, because it's been a while since I paid attention, but unless a project takes it upon themselves to go through the process of becoming an Apple Developer (do they need to decide on a person, or form a non-profit, or can they somehow register as a non-legally recognized organization?), how doe they distribute a fully open source version with some assurance that what you're running on the device is what's in the open source repo? I'm much less interested in running someone's custom port of OpenSSH to work with a phone UI than I would be to run some official port by the OpenSSH/OpenBSD developers. How hard is it for someone to harvest private keys, passwords and remote IPs in an app like that? Not very hard at all. Breaking the chain of trust between the repo and what I can build myself (or trust a third party to do, such as a linux distro) makes it much less appealing.
blihp 8y ago
I'd read the 'by default' as it being turned on system-wide and up to the user to override on a per case basis. Of course Apple's ideal model is that they want everything going through them. They're going to enable it 'by default' and if customers don't scream too much, they'll likely make it mandatory a release or two later.
captaincrowbar 8y ago
"Currently, if a user tries to run your software it simply won't run, and the user has to know to go into system settings and manually give it permission." No, you don't need to go into system settings. Just right-click on the app and select "Open" from the context menu. This brings up an are-you-sure dialog that gives you the option to go ahead and run the app. If you choose to run it, Gatekeeper marks it as trusted and won't bother you about it next time.
- chronogram 8y ago
  Huh, I didn’t know of this but I did know about the settings and “sudo spctl --master-disable”. It’s probably supposed to be something you come across about as frequently as terminal commands for some then.
  - mosselman 8y ago
    When the restricties was first introduced I duck duck go-ed for a few second and came across the right-click-open solution straight away.
    - pjmlp 8y ago
      It was also shown at WWDC.
eridius 8y ago
I interpret the "by default" as meaning the exact same thing as "Developer ID is required by default for Mac apps" today. Or in other words, I would assume that getting around a non-notarized app in the future would have the exact same sequence of steps as getting around a non-Developer ID-signed app today.
month13 8y ago
GateKeeper (the mechanism that enforces this) can be easily disabled. It could even be disabled from the UI, up until a few releases ago.
raxxorrax 8y ago
I don't know about the landscape on macOS, but aren't signed apps still the exception? I hate signed apps to be honest. They ruined the software landscape on mobile, and I don't want to see any of this on a machine that is used for work. Security advantages are marginal, the lock-in isn't.
princekolt 8y ago
What you describe in your point number 3 is not for apps, but for kexts (Kernel Extensions). Upon installation they won't run by default, but the user is allowed to go to System Preferences > Security and give it permission to run.

Wevah 8y ago

My understanding is that if you’ve released Developer ID-signed software in the past, you won’t have to notarize just yet.

RHSeeger 8y ago

How does it work if you want to write your own software and run it locally on your machine?

opportune 8y ago
You just chmod it, in my experience. Not sure what happens if you need to really install something on your own machine
month13 8y ago
I'd imagine it's another tier for Gatekeeper (the mechanism in macOS that verifies this). Gatekeeper can be outright disabled if desired (appears missing from the System Preferences UI though), allowing all unsigned code to run. Currently, if an app isn't signed and you have Gatekeeper set to "Allow apps downloaded from App Store and Identified Developers", you'll get a prompt stating it isn't permitted to run. If you open it using the context menu, you'll get a button in that prompt to "Run Anyway". Alternatively, recently blocked apps by Gatekeeper appear in System Preferences allowing for manual override as well. I'd imaging the notary service would be included in the "App Store and Identified Developers" section, and the same restrictions apply. As for your own software, XCode signs it with your Apple ID automatically. Everything else, via terminal is the same as always.
captaincrowbar 8y ago
There's no interaction with Gatekeeper there. An executable you've built yourself will just run normally (assuming it has the x attribute of course). OK, quick lesson in how Gatekeeper works: When you download a Mac app from the web, or save it from an email, a bit of metadata called the "quarantine attribute" is attached to it. When you try to run an app with the QA, Gatekeeper checks whether it's allowed to run; by default this will be allowed if it's signed. If it doesn't pass GK, you can still run it anyway by right-clicking on it and choosing "Open". When the app runs, regardless of whether GK passed it or you overrode GK, the QA is removed. After that GK no longer cares about it, and the app will just run normally without further fuss. Safari and Apple Mail automatically add the QA to anything they download, and most 3rd party browsers and email clients now do the same. But if you download an app using most command line tools (curl, wget, ftp, scp, etc), or if you build it yourself from source, then the QA never gets attached to it in the first place, so GK doesn't care about it and the app just runs normally. As far as I can tell the new notarization system doesn't change any of this, it just adds another form of code signing.

opportune 8y ago

If they get rid of option 3, they will make macs unsuitable for a lot of development outside of the Apple ecosystem (they must still be good for development for iOS and macOS apps). Surely that is a large enough part of their userbase that they won't just throw that away

tambourine_man 8y ago
>Surely that is a large enough part of their userbase that they won't just throw that away Don’t be so sure. It’s truly impossible to predict and understand some of decisions Apple's made in the pro market. Best one can hope for is to get an explanation 10 years from now in a podcast or blog post. If there’s still such a thing
- inlined 8y ago
  Surely you can turn on option 3 indefinitely for local builds at least. Otherwise Apple kills the ability to develop any software while offline or behind a firewall.
  - jakobegger 8y ago
    Gatekeeper only applies to software downloaded from the internet. Browsers set the "quarantine" attribute for downloaded files, and then Gatekeeper kicks in on first launch. Software that you build locally, or that you install with a package manager, is not affected. The goal of Gatekeeper is to keep your Mac safe -- not to control what you can do on your Mac.
    - puzzledobserver 8y ago
      Would something like "cat a.out > b.out" bypass Gatekeeper? I am always puzzled by apps which know the origins of files that they open.
      - true_religion 8y ago

willio58 8y ago

As a life long Mac user, if option 3 is removed i will be leaving for Linux.

mark_l_watson 8y ago
Yup. I have a MacBook and a really nice Linux laptop. While I work a little faster in the Mac, it feels good running Linux. I don’t think I would be OK with option 3 - agree with you. EDIT: I am fine with a sandbox for iOS, not macOS.
- teamspirit 8y ago
  This is why I still haven't bought a tablet. I was really excited to get the latest iPad with the A12 bionic, then I started looking into open source software (only really need two: password store and ssh) and realized it essentially doesn't exist. And with the current state of Android tablets, I guess I just won't be getting one for a while.
  - saagarjha 8y ago
    There are plenty of SSH and password management apps on iOS. Did they not work for you?
    - kbenson 8y ago
      Open Source is what he said doesn't exist. I'm not sure, because it's been a while since I paid attention, but unless a project takes it upon themselves to go through the process of becoming an Apple Developer (do they need to decide on a person, or form a non-profit, or can they somehow register as a non-legally recognized organization?), how doe they distribute a fully open source version with some assurance that what you're running on the device is what's in the open source repo? I'm much less interested in running someone's custom port of OpenSSH to work with a phone UI than I would be to run some official port by the OpenSSH/OpenBSD developers. How hard is it for someone to harvest private keys, passwords and remote IPs in an app like that? Not very hard at all. Breaking the chain of trust between the repo and what I can build myself (or trust a third party to do, such as a linux distro) makes it much less appealing.

blihp 8y ago

I'd read the 'by default' as it being turned on system-wide and up to the user to override on a per case basis. Of course Apple's ideal model is that they want everything going through them. They're going to enable it 'by default' and if customers don't scream too much, they'll likely make it mandatory a release or two later.

captaincrowbar 8y ago

"Currently, if a user tries to run your software it simply won't run, and the user has to know to go into system settings and manually give it permission." No, you don't need to go into system settings. Just right-click on the app and select "Open" from the context menu. This brings up an are-you-sure dialog that gives you the option to go ahead and run the app. If you choose to run it, Gatekeeper marks it as trusted and won't bother you about it next time.

chronogram 8y ago
Huh, I didn’t know of this but I did know about the settings and “sudo spctl --master-disable”. It’s probably supposed to be something you come across about as frequently as terminal commands for some then.
- mosselman 8y ago
  When the restricties was first introduced I duck duck go-ed for a few second and came across the right-click-open solution straight away.
  - pjmlp 8y ago
    It was also shown at WWDC.

eridius 8y ago

I interpret the "by default" as meaning the exact same thing as "Developer ID is required by default for Mac apps" today. Or in other words, I would assume that getting around a non-notarized app in the future would have the exact same sequence of steps as getting around a non-Developer ID-signed app today.

month13 8y ago

GateKeeper (the mechanism that enforces this) can be easily disabled. It could even be disabled from the UI, up until a few releases ago.

raxxorrax 8y ago

I don't know about the landscape on macOS, but aren't signed apps still the exception? I hate signed apps to be honest. They ruined the software landscape on mobile, and I don't want to see any of this on a machine that is used for work. Security advantages are marginal, the lock-in isn't.

princekolt 8y ago

What you describe in your point number 3 is not for apps, but for kexts (Kernel Extensions). Upon installation they won't run by default, but the user is allowed to go to System Preferences > Security and give it permission to run.