This is Apple's official line, but no one is going to actually have to do anything different if they don't want to. Some not-so-tech-savvy users might end up with apps they don't understand how to open after downloading them, but those are also the user most susceptible to falling for malicious downloads, so I'd call it a pretty good security feature.
Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS, or just here to beat a dead horse?
Anecdotally, I find that the people who are loudest about Apple's misdeeds (both real and assumed) are often people who've never even used an Apple product.
There is plenty of legit criticism of Apple to be made, and you certainly don't have to be an Apple customer to make it. But half the time what I see instead is pearl-clutching from people who don't have enough experience with the platform in question to tell what an announced change even does, blowing up what amount to minor inconveniences into the end of all life as we know it.
The other side of this is, when I complain about Apple not allowing sideloading on iOS, I get asked why I use an iPhone if I don't like the policy.
(fwiw, I have no issues with macOS as long as unsigned apps can still be run, and lots of issues with iOS where they cannot be.)
Other companies only require account for using non-OS API such as Firebase / Google Services for example.
Sure that's beyond the reach of most people, but how on earth do you people imagine that people develop and test new apps on iOS devices if you think an app _must_ be published to the App Store to run at all?
I kinda like that requirement because it means that I'm technically capable enough to make a potentially system-breaking change. It's not as nice and friendly about it as macOS but I think it's a fair compromise.
Interesting. The number of people of who I know that they have complained about Apple, and of who I also know that they have never used an Apple product is zero.
If one actually considers the spirit of my comment (people getting caught up in outrage about issues they can't actually judge properly), several of the comments of this very post make it pretty clear that their authors have likely never interacted with a Mac for a day in their lives but are nevertheless very opinionated about how this change will affect macOS users.
My comment was not a particularly long one. Try reading it through the end.
I was agreeing with this person that I responded to and talking about the one that you responded to.
It’s definitely easy to get confused with the HN ui though. I wish they would put vertical lines or something to the parent comment or just think of something better. I thought we had half of the worlds software geniuses here! Can’t we figure this out?
And those who are loudest about animal abuse in factory farming, don't eat meat.
Now, Apple is making that impossible, which hurts developers who can't afford to go all-in on the mac platform.
How do you test your software without the machine you're targeting? Every programmer knows that VMs aren't as good as the real thing.
Not everyone can afford to keep around a lab full of macs running multiple versions of macOS.
Judging my the reaction to my comment, Today I Learned it’s acceptable to release software with only cursory testing on a friend’s computer. Explains a lot about recent software quality actually...
I'm concerned at this point about if anybody that this supposedly effects has actually done any research at all on it.
I was concerned MacPorts would stop working on my computer. I don't plan on publishing apps for Mac, but I depend on apps others publish.
All MacPorts has to do is either avoid setting the quarantine bit in the first place (easy enough) or remove it. The quarantine bit is nothing more than an xattr called “com.apple.quarantine” which you can inspect or remove with the xattr tool.
> The MacPorts installer pkg will need to be submitted, but I don't think much else will change. Using MacPorts-built kernel extensions is already impossible because of signing requirements (we don't have a kext signing certificate and I don't think we qualify for one.)
> For general apps, Gatekeeper doesn't prevent running locally built ones due to them being unsigned, and I gather than notarization is only required in the same circumstances as signing. (It would be incredibly inconvenient for developers to test anything if this were not the case.)
> * For 10.14 users: The pkg meets Apple's new requirements for notarization. This includes enabling the hardened runtime for all executables, which has the potential to cause new issues due to denying access to certain system resources and preventing the loading of unsigned plugins. Please let us know about any such problems.
MacPorts .pkg installers are notarized since 2.6.0.
You also couldn't notarize old apps that weren't built with secure timestamp, hardened runtime, etc (a lot of versions of some software I'm supporting back to 10.7 preexisted some of the required criteria) until the beta release that coincided with this announcement in early September.
I think Apple relaxed their stance here because they did not want the average person to think that Catalina was breaking their apps and have subsequently deferred their "hardening" to January 2020.
"message": "The signature does not include a secure timestamp.",
"message": "The executable does not have the hardened runtime enabled.",
In my opinion, a number of people in these threads are missing the point when they suggest: "You can easily run these programs if you just do these quick tricks like using the command line or removing an xattr from the file or a special click workflow" There are companies out there making software for normal people (ie non technical) who will think your app is broken if double clicking doesn't work. These people will call your support lines and this will cost your company money
Two months? So Catalina will start breaking apps for average users after only two months? It hardly seems worth it for Apple to have that short of a delay.
I think you answered your own question there.
People have to stop treating betas like gospel.
I've always viewed a beta as a way to test that my app has not regressed. If it has, I open issues with Apple (or whomever). If these issues are either cited as not-to-be-fixed or I hear nothing back, I will create a release of my apps that works around whatever issues are there. IMO determining breaking changes in beta versions allows one to develop fixes as well as create and plan the rollout of the new software before the beta goes lives (and therefore avoid any regression/downtime).
Yes. I take offense to you generalizing all complaints as just wanting to "beat a dead horse"
I find this a common problem when it comes to just about anything these days including tech sites where I appreciate that the local community generally is knowledgeable and the likelihood is high that someone(s) has granular knowledge of the topic.
I was under the impression there's a process involved with Apple to approve these things. From: https://developer.apple.com/documentation/security/notarizin...
"Give users even more confidence in your software by submitting it to Apple for notarization"
So it seems the "key" difference here is that while most Linux package managers seem to use GPG to sign based on the author's verification, here Apple is the trusted source, forcing application authors to bow down and submit to review (even if it's automated).
Whereas for all GPG packages I just sign the same way, here my process is different, and Apple is forcing my hand.
Don't get me wrong, I don't want users getting viruses or generally bad software any more than the next guy, but it seems out of place to rely on some specific Apple protocol to do this. Though, it doesn't surprise me at all that Apple wouldn't try to "play nice" in this space.
Edit: further reading finds the following.
"Notarization requires Xcode 10 or later. Building a new app for notarization requires macOS 10.13.6 or later. Stapling an app requires macOS 10.12 or later."
As a developer of some cross platform applications who happily doesn't know anything about Xcode (and plans to keep things that way) I'm upset by this.
You're under the wrong impression.
Think of it more like Google's certificate-transparency log.
Apple will have a log of all applications distributed outside of the app-store and macs can consult this transparency log during installation and warn the user if (a) Apple has revoked the certificate because Malware has been detected or (b) the developer who made the software being installed doesn't have an email address. Users will still be free to ignore the error messages (just as they are on Linux and Windows).
> As a developer of some cross platform applications who happily doesn't know anything about Xcode (and plans to keep things that way) I'm upset by this.
I generally advise people to not get upset about things they don't understand and don't care to understand. It feels strange to me that I feel have to give that advice, but what else can I do? People might read your (well-written) comment and develop the same fears and hysteria you have about something they don't understand either, but care to, and that makes the world a worse place.
I wouldn't say I don't care to understand. In fact quite the opposite. If someone can explain to me how this process should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
But what fears and hysterias are you talking about? I quote Apple's own developer material, and complain about what it says. I don't want to deal with Xcode to package apps for macOS, sorry. And I find it somewhat oppressive to force communication upstream to Apple in order to run applications smoothly on their OS.
> I find it somewhat oppressive to force communication upstream to Apple in order to run applications smoothly on their OS.
Yeah, I know, but that's what packaging and releasing is.
On Debian, you need to contact Debian (or a Debian packager) to make your application easy to install and run on Debian because the Debian expectation is that the user runs apt install myprogram to install it, and navigates to the menu and clicks on myprogram to run it.
On Fedora, same same, but with Fedora (and it's rpm/yum/dnf).
On FreeBSD, same same, but with FreeBSD (and it's ports, etc).
And so on.
About the only operating system where the user-expectation was you don't need to talk to anyone is Microsoft, and building the expectation into users that programs can "come from anywhere" is why we had so much malware and junk on Windows. This wasn't a good thing.
I suggest you just get over this. It's better for macOS users, and it doesn't impact power users at all.
> what fears and hysterias are you talking about?
Look around this thread: It's chock full of fudding about how Apple is taking away their freedoms of some kinds, or there's a slippery slope, or that this somehow isn't 100% better for end-users (the people who buy Apple products).
How is having a lot of people afraid about nothing a good thing?
> If someone can explain to me how this process should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
I mean, I'm happy to teach you, but I don't work for free. What do I get out of it?
So you project your frustrations with them onto me?
But given how you'd rather type up a long winded rant about ranters rather than answer my simple question, I suspect you either don't know how to do it, or it's in fact not possible. I'm not trying to get free lessons, I'm trying to get someone to prove to me how this works.
Does this work on your tax preparer? I suspect you either don't know how to do my taxes, or it's in fact not possible.
Does this work on your driving instructor? I suspect you either don't know how to drive a car, or it's in fact not possible.
Does this work on your plumber? I suspect you either don't know how to unclog my toilet, or it's in fact not possible.
No? So why the fuck would you think it would work on me?
> But given how you'd rather type up a long winded rant about ranters rather than answer my simple question: If someone can explain to me how this process [of packaging and signing] should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
As short a statement this is, it's not a question, let alone a simple question.
I typically charge companies as much as £30k a week to listen to "questions" like this, and I'm not much interested in doing it for free on the Internet. If you can figure out how to ask a question maybe someone will answer it (heck, maybe it will even be me), but if this is how you want to talk to me it'll have to be at my day rate.
Gatekeeper really isn't a stringent measure, it just protects people who don't know what they're doing.
Ed: seems there is a more general check now - but limited to checking against known "malware" - not "whitelist" (motorized)
But just from a security and privacy perspective, why would a non-admin be downloading and installing random software packages?
It's also the default policy of my work, a university. Staff do have local administrator access to their machines, but are not supposed to use it for regular operations for safety.
Once the software is installed, I can use it from my regular account.
> Staff do have local administrator access to their machines, but are not supposed to use it for regular operations for safety.
The point of this exercise is that installing random software from the Internet shouldn't be a regular operation; users should take extra care when doing it.
So...elevate permissions when you need to perform this new administrative task? I don't see how that changes the crux of the matter (you still are the de facto admin, even though you've applied artificial constraints to yourself, because you hold the admin credentials).
Do you use macOS?
> Do you use macOS?
They should be able to download and app and use it without having to call tech support.
Anti-user features like intrusive telemetry are standard fare in commercial software, and running those apps in a sandbox could protect the user without having to rely on Apple's approval system.
It isn't if the user wants to use software that isn't available on the App Store.
Arbitrary programs can be run with the macOS sandbox, there is no need for the App Store for security.
Accounts ought to be granted privileges based on the user's need to get things done.
Most consumer laptops and PCs I've seen (and I've seen a lot) don't even have a non-admin user account setup.
in macOS, even if you run as admin, the only thing that gives you is `sudo` access. Your "admin" user still is a normal user, but it's allowed to gain elevated privileges by supplying their password (or doing biometric auth).
The only difference between running as an admin and not running as an admin is that in the former case you don't have to type in your user name.
>having to elevate to an admin account in order to "download anything" would be a nightmare for any substantial IT department to support
normal users can download all they want. They can't execute it though. That's absolutely what I would like my machine to be configured as.
Who disagrees with that? For most users, by a long shot, installing software is only a tiny fraction of the tasks they perform.
Anybody, including that substantial IT department has to elevate to an admin account to install software, and that is a good thing.
Any halfway smart IT department won’t have to type an admin password on every machine or even visit every machine, though.
> Most consumer laptops and PCs I've seen (and I've seen a lot) don't even have a non-admin user account setup.
Have you ever used macOS or are you basing this on Windows laptops?
If so that's a huge barrier.
I have the chicken and egg problem.
I refuse to develop for Apple due to their anti-developer and anti-consumer policies.
So would I make Apps for Apple is they played nicely? Yes.
But anti-consumer? How is this anything but good for 99% of Mac users? It keeps totally un-savvy users safer, puts savvier users on high alert, and doesn’t affect power users at all (other than the minor inconvenience of right clicking the first time you open a non-notarized app).
This is such a HN comment. On what planet is it Apple's responsibility to maintain their operating system in such a way that third-party apps from developers who don't give a shit about maintaining compatibility can continue running until the heat death of the universe? It's like being angry that Microsoft didn't stick with 8.3 character filenames forever.
On planet Earth.
> who don't give a shit about maintaining compatibility
Or the developer does not exist anymore or has "pivoted" to something else entirely or has discontinued the program or they have no funds to do the conversion or they rely on technologies by others that (do not exist anymore, have "pivoted" to something else entirely, have discontinued the technology, have no funds to do the conversion, rely on technologies by others that (do not exits anymore, ...)), or simply the newer version is undesirable for the user (due to worse UI/UX, lower performance, monetization-driven user-hostile changes, etc).
As a user all i care about my programs keep working.
> It's like being angry that Microsoft didn't stick with 8.3 character filenames forever.
When Microsoft introduced long file names it was implemented in a way that was backwards compatible with existing software in a way that would be possible to both use existing volumes with 8.3 format, add/rename files with long filenames and have those be visible in a 8.3 form for compatibility with older software.
And 8.3 character compatibility still exists on Windows 10. For example if you have any GOG games installed you can type DIR C:\GOGGAM~1 on command prompt to see the contents of C:\GOG Games. You can disable this via the registry, but it is enabled for backwards compatibility.
Here's a quick summary:
App Notarisation is enforced by Gatekeeper. Gatekeeper only checks software with the "quarantined" attribute . The "quarantined" attribute is set by web browsers, email clients, messaging apps, etc.
So this means that Gatekeeper does not check software installed with curl / brew / port.
You can circumvent Gatekeeper by right-clicking the file in Finder, or by removing the quarantine attribute.
A change from previous versions of macOS is that Gatekeeper now also checks programs you start from the command line (if they have the quarantine attribute set).
: https://developer.apple.com/videos/play/wwdc2019/701/ (Transcript: https://asciiwwdc.com/2019/sessions/701)
: Actually Gatekeeper now also checks programs that don't have the quarantine attribute set, but it only checks the signature against a known malware database, and doesn't require notarisation. Details are in the video linked above.
xattr -d com.apple.quarantine FILE
Before notarization, when this bit was set, the user would receive a simple warning that the software was downloaded from the internet and they should proceed with caution.
All notarization does is add additional logic to this flow. If the notarization is "stapled" to the executable, then macOS can verify it offline, otherwise macOS will connect to Apple's servers to verify the notarization of an app/binary. This means that by notarizing an existing app, you do not need to re-distribute it.
This quarantine bit behavior is why upgrading to Catalina does not impact previously installed apps (regardless of their notarization status) as they do not have this bit set.
Given the history of what Apple did in the past, I think it's very naive that this is the last restriction Apple will add.
First the user could run any app.
Then you had to sign the app or the user would see a scary warning.
Then you had to sign the app or, by default, the user could not open the app, unless he enables it via a UI that is very confusing (and I assume on purpose).
Now you have to notorize the app.
It's pretty clear that the end goal for Apple is to lock down Mac OS the same way they locked down iOS.
Apple needs to protect the hostages, I mean users, from the likes of Mozilla which produces a dangerous app that duplicates built-in OS functionality, which is confusing. And it can deliver porn so think of the children!
And they will in Mac OS 10.20, unless the government steps in.
I agree. All this infrastructure and support doesn't make sense if it is only used on executables that have some easily modifiable fs attribute set.
I fully expect apple to try to expand this on all executables at some point in the future. It'll be interesting to see if they will be able to pull it off.
And for 10.17, Developers will have to pay for notarization, as an "insurance" low quality app will not end on your Macbook.
For 10.18 or 10.19, nothing will run unless it's installed from the Apple store or certified with an enterprise certificate delivered by Apple. Just like on iOS.
Apple has previously expressed frustration about the poor financial performance of the Mac App Store...
They want to bring the iOS App Store business model on Mac in order to optimize financial return on the platform.
It's on par with the T2 ship insertion in new models in order to prevent third party repair (google Rossman macbook) just to be able to ask outrageous prices for minor repair or to push for the purchase of a new model at every random glitch on your device outside of the Apple Care contract or legal warranty..
Beside, in Catallina, they just put the /System folder as a separate partition in read only mode... But even if you can still currently mount it in read-write mode, in a future version it will not be possible anymore, unless if you start in recovery mode, system used by Apple to install new version of MacOS.
Soon, you will have to jailbreak your Macbook, taking advantage of a providential "bug" on a specific version, and lost all unix permission system benefits in order to install third party software (at that point cracked, because all legit developer will either have already paid for notarization/Mac App Store or abandonned the platform), just like on iOS.
It's all writen betweens the lines. They're just going forward slowly enough to avoid brutal outcry from the MacOS power users base and the press.
It was just a matter of time until the disease spread to the desktop.
I am no fan of RMS for many reasons, but one thing can no one can take away from him: he totally foresaw the curtailing of freedoms decades before anyone else did.
It's fully here now.
I expect the next step to be: if you use an unrestricted platform (Linux, OpenBSD, etc...), you won't be granted access to major chunks of the internet.
And then next: if you want to use Linux, you'll need the IT equivalent of a carry permit from the govt.
We already have this in the form of browser drm modules. It's not hard to imagine similar modules being implemented for network stacks. ISPs and internet exchanges can be required by law to drop any unencrypted traffic.
Lock down is an inevitability for any technology. General computing, Machine learning, Encryption, and other technology will inevitably get locked behind a sea of regulation. The only way to combat this is to keep governments playing catch up by innovating faster than they can legislate (e.g. mesh networks as a response to telecom overregulation).
$ sudo spctl --master-disable
Everyone else will bypass protections and continue as before.
I think the security effect will be marginal.
Is this Apple's position, or is their position that apps you install on your system should be vetted in some way (either via the App Store, or via the notarization process)? It seems to be the latter based on reading the link, but I might be wrong.
There are various ways around this if you know what you're doing.
My new go-to for dev laptops is a System 76 machine . I am unaffiliated with System 76 in any way.
A follow-up post mentions that standard users will not see an Open button at all.
Installed casks didn't used to be quarantined at all. Quarantining installed casks was actually a Homebrew cask feature introduced in 2016:
Quarantining files is opt-in from the app perspective. Apps and programs (like Chrome and cask) have to explicitly support setting the quarantine bits on things they consider downloads. Apps and command-line programs create files all the time for all sorts of purposes, and without app cooperation, macOS has no idea whether each file is something potentially unsafe downloaded from the internet.
So hopefully this shifts the perspective a little. Makers of apps that download things _like_ quarantining because it distances them from the responsibility of ensuring the quality of each download, so much so that they will spend time to implement support for it. If quarantining isn't a good feature, apps like Chrome and cask wouldn't use it or would stop using it. This provides a great check and balance in the system imo.
Btw, there are two separate Homebrew projects that are unfortunately named -- one of them is named like a subset of the other. Here are some clarifications for people unfamiliar with this:
- `brew install` builds apps and programs from source, or downloads binaries built from source ("bottled") by machines maintained by the Homebrew project. Neither of these are quarantined, I think.
- `brew cask install` downloads and installs apps similarly to how you would install them manually, but in an automated way. (For example, it will download a dmg, mount it, copy the app to apps, and unmount the dmg.) My comment above is only about this option, and not the other one.
Or does it only check signatures when you're launching things from the GUI?
Items marked 'quarantine' get the "Are you sure?" (or "you can't" or "find another way" or whatever) dialog.
I think it checks things with the quarantine flag set on the executable or app. This is set by your browser and other similar software when downloading an app. Once cleared, the notarization check isn't done.
Brew doesn't set the quarantine flag in the first place as far as I know.
Yes. If you;re tinkering with Homebre, you are not the target demographic.
heh people probably need to chill out about all this. I got a mechanical engineering student (read: "doesn't understand computers") to play open arena with me the other month dispite all of this. It's just a couple buttons you have to press.
sudo spctl --master-disable
Part of me wishes that Apple would slow down the big innovation for a couple of years and get the entire development team working on bug-fixes and polish.
I attribute it to Apple focusing on iOS and letting their desktop products slide.
This process, agree with it or not, is meant to stop things that cannot be stopped with just basic security technology.
This is a real issue for me, as my open source project is a cross-platform game development tool. It used to be that it was possible for someone to click a button and get Linux, Windows, and Mac distributions - but now the Mac side is proving more and more difficult.
Maybe you do, I can't find any way besides using Xcode, either on the GUI or using "altool", which comes with it.
I owned a business focused on iOS and shut it down because of the dumpster fire the App Store has become. My livelihood will not depend on some halfwit middle manager.
The day they force Mac software through that dumpster fire is the day 100% of my Apple products go in the trash.
Enough with the fucking greed already.
Non-"notarized" software, when freshly downloaded to a computer running Catalina, will not run. A dialog will be displayed, telling the user that the developer needs to update their app for compatibility. There is no further indication telling the user what to do, and no "run anyway" button.
The developer will need to "notarize" the software with Apple, and receive their approval. If that happens, then the "notarization" information for the app bundle will be available via Apple's servers when users attempt to run the program, and Gatekeeper will attempt to look it up from the Apple's servers if the "notarization" information is not "stapled" into the app bundle. Optionally, and probably preferably, the app developer can "staple" the notarization information directly into the app bundle, and Gatekeeper won't need to look anything up over the internet the first time the user attempts to run the program.
It's basically an upgraded Gatekeeper. I'm not quite sure what the pearl-clutching is about.
I am...rather confused as to how you think people bring up context menus on macOS.
Unless you're being extremely pedantic and mean that I should call it "secondary-click" instead of "right-click", which wouldn't exactly be in the best of faith.
If you don't understand why that would be an issue for a company that sells applications outside of the App Store, I don't know what to tell you.
You literally just run the installer like anywhere else, what on earth are you talking about? How is that an esoteric instruction?
The scary thing to me is there's no "Open Anyway" button that was mentioned further up in the thread.
I haven't used Catalina yet though so I'm not super sure of all these facts.
Unsigned software will continue to work.
Give users even more confidence in your software by submitting it to Apple to be notarized. The service automatically scans your Developer ID-signed software and performs security checks. When it’s ready to export for distribution, a ticket is attached to your software to let Gatekeeper know it’s been notarized.
So, on this page it reads:
Mac software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina
What does this mean? Is this something that affects merely the default security setting?
There is a reason not everybody is using gentoo.
> brew cask quarantines, but not regular brew.
> ...which makes it all the more annoying for "power users" that there's no simple switch anymore to allow all apps to run without the scare/confirmation popups
You do, you just don't necessarily own the software running on it.
What do you want “own” to mean, exactly? What do you want to do with your software that you can’t do right now?
"Hey, you can have your software notirized (which we might not accept), people will be warned before opening the app and some other bs or you can pay us 99$ and stop worrying!"
By introducing themselves as gatekeepers, they can analyse software and reject it. For example, if they decide to deprecate an API, they can decline to notarise any software that uses it.
The thin end of the wedge is, of course, free notarisation with few limitations. Then once that is in place, they can increase their power to the level they enjoy in the iPhone app store.
Crapware is a substantial cause of 'my machine's not working properly' among the less technically savvy
You also can download malware on the App Store.
I read a bit about it because I wanted to do it myself but I haven't upgraded from Sierra yet due to no support/broken for my audio hardware in newer versions.