Because zoom’s patch will only help users still using and updating zoom while those who have uninstalled zoom are still vulnerable (because the uninstalled leaves the web server behind)
For cripes sake...
But Flatpak! Flatpak applications can be sandboxed and you can install/remove applications as one unit.
If so, it doesn’t seem much better.
Something an app store due to volume and default allow pending mostly automated checks has a problem with.
the problem in this case is that the developers just couldn't be assed even trying.
This is false. Kernel extensions can be part of the application bundle and will be unloaded and removed when the bundle is removed.
Installing KEXTs in an application bundle allows an application to register those KEXTs without the need to install them permanently elsewhere within the system hierarchy. This may be more convenient and allows the KEXT to be associated with a specific, running application. When it starts, the application can register the KEXT and, if desired, unregister it on exit.
For example, a network packet sniffer application might employ a Network Kernel Extension (NKE). A tape backup application would require that a tape driver be loaded during the duration of the backup process. When the application exits, the kernel extension is no longer needed and can be unloaded.
Source: https://developer.apple.com/library/archive/documentation/Da...
You can also launch agents that are part of your application bundle:
https://developer.apple.com/documentation/servicemanagement/...
It is true that you cannot remove application data, but that is a feature (maybe users want to retain the data) and also does not happen in e.g. Linux package managers.
Apple also makes a fantastic computing platform with very good mandatory isolation, namely, iOS. If you're interested in isolation in preference to compatibility with traditional desktop software, an unjailbroken iPad Pro with Smart Keyboard is a pretty good option.
Remember old school Mac was full of hacks upon hacks upon hacks, many by third parties, and there was cool stuff in there too. The App Store mentality has caused everyone to overreact and think that every third party app on the planet will turn into the worst conception of Win98 era malware overnight if unconstrained, when this is just one outcome among many possible.
The sandbox only applies to software devs that want to use it or those that wish to sell through the Mac App Store. I don't think Zoom is in the MAS at all (I don't see it in a quick search anyway), and a standalone installer is free to do whatever it wants and can convince users to go along with (up to and including, in principle, bypassing SIP though since that significantly raises the effort bar I've only ever seen niche stuff request it). And it's completely legitimate to want to run a server on your system too, there is no hole. Zoom simply acted as malware, taking actions without user permission.
Future versions of macOS will require signed software (notarized as per Apple terminology), even outside of the store.
What is new in security at WWDC.
A path similar to how Windows 10 is now converging the Win32 and UWP sanbox models, or how ChromeOS sandboxes GNU/Linux processes.
I do not see where this is mentioned.
I haven't looked enough to understand what is gained by notary. Does Apple want to search your binary for maliciousness or rulebreaking (potentially even at a later date) so that it might revoke the notarization/signature?
"Advances in macOS Security"
https://developer.apple.com/videos/play/wwdc2019/701/
"All About Notarization"
Some of this stuff seems a tad disingenuous. Like preventing debugging. The debugger APIs on Mac already pop up a password prompt, limiting the usability in malware (and actual use, like trying to debug over ssh). Meanwhile, a culture of producing separate binaries for debug and for end users (debug builds lacking optimization, allowing additional permissions) is in my experience a great way to fail to reproduce legit customer-facing bugs during development and have greater difficulty diagnosing them when they occur on a real live user machine.
Many open source projects will not participate in this.
If this kills brew you will also loose a lot of devs.
Neither do game consoles or the large population using Windows based systems.
I never cared for brew on the occasional moments I get to use Apple computers, XCode and default tooling is more than enough.
Which is like what the large majority of developers targeting Apple devices actually care about.
Then again, I only hang around with Mac devs that target iDevices and macOS, using Objective-C, Swift, C++ and Web.
On my Mac circle it is all about store apps and Web apps (Java/.NET Core based).
I personally don't use Homebrew, et al. but, I have a Linux VM which handles that stuff pretty well.
I didn't develop a Mac specific "application" though.
There is still the same control-click to open non signed software and there is still no aggressive permission model outside of the App Store.
Firefox was broken on Catalina for a while, even though the main app was notarized. Some internal binary wasn't notarized, and no amount of control clicking would get Firefox to work until Mozilla notarized everything in the build.
https://forums.macrumors.com/threads/unsigned-apps-catalyst-...
sudo spctl --master-disableI have a Raspberry Pi for hacking, I'm happy to root the hobby computers, not the work ones.
It seems like this conflates the notion of having root privileges with turning off security. There is no meaningful connection between the two save in situations where there is no meaningful way to control said security layers save destroying them.
For example refusing to boot a bootloader that isn't signed doesn't require your oem to hold the only possible key that can be used to sign said bootloader.