Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
OS X Security Software Apple

macOS Sequoia Makes It Harder To Run Apps That Aren't Properly Signed or Notarized (9to5mac.com) 82

Posted by BeauHD from the no-more-shortcuts dept.
Ryan Christoffel writes via 9to5Mac: Since the Mac doesn't have the same locked-down app distribution system of iOS and iPadOS, Apple has created other tools meant to protect users. Some of those tools include app signing and notarization. Essentially, these provide a way for Apple to perform a level of vetting for macOS apps, even ones that don't hit the Mac App Store. The intent is to ultimately prevent harmful software from being inadvertently opened by Mac users. Trying to open an app that isn't correctly signed or notarized results in some scary warnings. But until now, power users could bypass those warnings -- and Apple's overall security process -- using a Control-click shortcut. But that shortcut is going away in macOS Sequoia.

According to a new post on the Apple Developer site: "In macOS Sequoia, users will no longer be able to Control-click to override Gatekeeper when opening software that isn't signed correctly or notarized. They'll need to visit System Settings > Privacy & Security to review security information for software before allowing it to run." The post then urges developers to make sure their software is properly signed so users won't need to jump through these hoops.
This discussion has been archived. No new comments can be posted.

macOS Sequoia Makes It Harder To Run Apps That Aren't Properly Signed or Notarized More

macOS Sequoia Makes It Harder To Run Apps That Aren't Properly Signed or Notarized

Comments Filter:
  • You no download from internet... IRREGAL! [youtube.com]

    • I mean, there are lots of reasons to hate on Apple and their walled garden, but this isn't one of them.

      I wish that Microsoft would do this. There is no reason, in this day and age, to distribute commercial software executables that are not signed. I see this all the time on Windows and it drives me crazy.

      • So, you don't care if it cuts clients off from Free Software and forces devs through some gauntlet (that might cost $$$) in order just to be able to support a certain platform? Do you mean in a big company environment or just across the board? Seems like a dangerous mentality that could leave you at the mercy of one vendor and a handful of their buddies. Then again, if you're a Windows fan, this all probably seems like "Hey, what's the big deal?"

        • If you are selling your software for money or are charging for support for your software then you should be able to afford a code signing certificate.

          That's all I am advocating for. Just sign your damn code. Without that signature, I am forced to trust the supply chain.

          Code signing is not a silver bullet, but it is far, far, better than blind trust in the supply chain.

          • Code signing is not a silver bullet, but it is far, far, better than blind trust in the supply chain.

            You're just subbing blind trust in the code signing (a potential vulnerability) versus the supply chain. I see zero value in having some untrustworthy asshole at a corporation sign the code. All it really means is that once someone steals the signing key you have another huge problem. What I'm saying isn't theoretical, either. It's happened multiple times such as in the case of the DigiNotar Hack, Stuxnet, Shadowhammer, and the Lenovo Superfish Scandal.

            Most crypto just gives you a false sense of security

  • Apples reasoning for this sounds plausible and I'm inclined to believe them.

    However, that does not include other b*llshit they've been up to lately. Like, for instance, hijacking and basically locking down the play button to show Apple music ads after I've dropped roughly 4k Euros on their premium grade laptop. You literally have to install an open source system demon to regain control of the play-button and connect it to some other function other than Apple music. Totally unacceptable for a machine in that

    • The play button seems to work fine for me for browser content. It defaults to whatever you happen to be running at the time.
    • You might be happier if you just switch to Linux. It worked for me.

      I really want a 3D window Manager, though.

    • I miss the days when macbook batteries were simple replacements, and you could actually upgrade your ram after the initial purchase.

      I'm still stuck in macos, but I'm no longer eager for new apple products. I used to be the guy who lined up outside the shop when there was a new hardware release, and now when I upgrade, I generally buy used.

  • Moving something like this to a more secure location will not be barrier for technical users that wish to bypass it, but will make it harder for malware providers to trick people into running it.

    I have no issue with it and since there are a lot of non-technical people using Macs caution is not a bad idea here.

    • I had to self sign a gdb that I built myself, way back, because anything that got process data had to be signed. Self signing your own app was a royal pain in the ass. The process is somewhat straight forward once you've done it and look back, but there are enough steps that you can mess it up if you're not paying close attention.

      • Self signing your own app was a royal pain in the ass.

        Xcode has made this much better over the years, it would probably be a lot easier now. As long as you have Xcode wired into your development account it can auto generate certificates and profiles you need.

        I only speak from the standpoint of signing iOS apps though, have not trie to self-sign a Mac app (although I guess come to think of it I have run a few downloads Mac projects to try some things which probably self-signed the executable to run).

        At thi

        • Nope, xcode was never part of our development cycle. We weren't doing iOS, and the programs we were building natively were from Unix sources and makefiles, not some one-shot IDE. Let's say we have an automated build process, then the signing still has to be doable via command line tools because xcode is a GUI. (we did have some portions of one build that required a manual clicking of buttons in an obscure IDE, but we fixed that later with a command line tool once the original dev left and we got sick of t

    • Re: (Score:2)

      by jythie ( 914043 )
      Yeah.. I am thinking back to when windows introduced that 'are you sure you want to run this?' dialog box and all it did was train people to click through with less and less thought. After having spent years working in SELinux environments where everything unknown was 'no' by default and you had to take explicit (but one time) steps to say 'yes, I do want this application to do XYZ', I found it to be a good compromise of forcing you to stop and think while not getting in the way of getting work done.

    • Moving something like this to a more secure location will not be barrier for technical users that wish to bypass it, but will make it harder for malware providers to trick people into running it.

      I have no issue with it and since there are a lot of non-technical people using Macs caution is not a bad idea here.

      Especially in light of Craig Federighi's recent Court Testimony in which he complained that, although Necessary on macOS, the ability to Install software from any location and any publisher had definitely compromised the Security of that Platform.

      • That testimony should tell you everything you need to know about that platform then. I.e. Apple owns it and you just use it at their pleasure.

        Not that it will happen, but it would be nice to see some consistency from the courts here. I.e. Because Apple owns the platform, they should be held legally liable for their users actions which Apple has ultimate control over.

        • That testimony should tell you everything you need to know about that platform then. I.e. Apple owns it and you just use it at their pleasure.

          Not that it will happen, but it would be nice to see some consistency from the courts here. I.e. Because Apple owns the platform, they should be held legally liable for their users actions which Apple has ultimate control over.

          Yeahrightsure.

          To both of your statements.

  • Power users do not CTRL-click (Score:5, Informative)

    by Zolmarchus ( 2646979 ) on Wednesday August 07, 2024 @06:08PM (#64688994)

    Nerd note, but power users use the xattr tool to remove the extended attribute(s), for example com.apple.quarantine. As long as this still works, the actual power users will not be affected.

    • Yeah, exactly. When I read the article, I realised that I remembered hearing of this approach before, but Iâ(TM)ve never used it. The story seems to be a bit of a dog whistle, which has worked judging by some of the knee-jerk comments here, many be people who clearly donâ(TM)t use macOS. Problems today are invariably related to incorrect code signing or quarantine, both of which are easy enough to resolve. So, Iâ(TM)ll see if there really are any issues when it comes out.

    • Or, use Folder Actions to attach Unquarantine.scpt to your Downloads folder, which runs the xattr command on anything added to it.
    • That won't work here. Unsigned and non-notarized executables are prevented from running by Gatekeeper regardless of whether or not there's a quarantine attribute. That's a totally separate protection. Removing the quarantine attribute simply bypasses the prompt to ensure you want to run an executable downloaded from the internet.

  • War on general purpose computing... (Score:5, Insightful)

    by firewrought ( 36952 ) on Wednesday August 07, 2024 @06:14PM (#64689004)
    Apple is boiling the frog of user freedom so they can wall off a new garden and extract more rent from app developers. It's a shame to see so many slashdotters defending this behavior.

    • Re: (Score:3, Interesting)

      by RazorSharp ( 1418697 )

      It's really hard to have an OS that can be protected against the most malicious actors out there: the users. Most people have no idea how file hierarchies work, they do not know how to type in a domain name to get to a website, and they cannot tell the difference between legitimate software and malware. Don't even bother getting into permissions!

      Securing an OS against its users is extremely difficult and Apple has done a better job than anyone. Windows has notoriously done everything wrong, from starting as

      • Most people have no idea how file hierarchies work, they do not know how to type in a domain name to get to a website, and they cannot tell the difference between legitimate software and malware.

        Because that is what they wanted from the start, ignorant users

      • Securing an OS against its users

        Stop right there. That statement alone means you're doing it wrong. The purpose of the OS is to serve it's users NOT act against them. If you have to "secure" OS against the users, you've fundamentally lost all justification for your OS' existence.

        Windows has notoriously done everything wrong

        Originally, Windows wasn't trying to be walled garden. "Notorious" is a bit much when the stated goals are so diametrically opposed.

        starting as a single user OS

        Have you seen Mac OS versions prior to X?

        trying to maintain backwards compatibility with prehistoric software

        Rosetta is a thing, and Apple has been doing this with each new CPU arch for decades.

        The worst possible solution to novice security is antivirus apps

        A

        • Rosetta is a thing, and Apple has been doing this with each new CPU arch for decades.

          True. However, there's a difference in how far back Microsoft and Apple take their backward-compatibility, with Apple dropping the binary translation a few major versions into an ISA transition. Apple dropped 68K emulation along with the rest of Classic in Leopard (10.5) in 2007, dropped PowerPC Rosetta in Lion (10.7) in 2011, and dropped 32-bit x86 userland in Catalina Wine Killer (10.15) in 2019. Windows 11's backward compatibility with apps targeting Windows 98 is like still being able to run software ma

    • I agree with you. Some details, like the fact that Apple previously promised to make this feature optional [lapcatsoftware.com], are particularly shameful.There will be a lot of metal gymnastics from some quarters to justify this.

    • Re: (Score:2, Troll)

      by laughing_badger ( 628416 )

      Deliver the source code of your application to your users and they won't have this issue - it's a shame to see so many slashdotters defending closed-source software.

    • Re: (Score:1)

      by mjwx ( 966435 )

      Apple is boiling the frog of user freedom so they can wall off a new garden and extract more rent from app developers. It's a shame to see so many slashdotters defending this behavior.

      When has Apple ever been the proponent of end user freedom. It's always been "our way or the highway" with them. They've never been afraid to burn their user base, the only difference is now, their user base is broad enough that burning them will turn a lot of people off Apple products.

      A subset of Slashdotters have always been shameless Apple fanboys and defend anything they do. Apple could use the tears of orphans to make their products and they'd still defend it with "the orphans would cry anyway and a

  • Do developers need to sign/notarize debug builds they create for troubleshooting or testing?

    • Yes.

      • Re: (Score:2)

        by berj ( 754323 )

        I've never had to. I regularly build local tools and plugins (for things like Maya and Houdini) and I've never signed anything. I just run make and compile and run. The only time I've ever had to interact with Gatekeeper was for binaries I've downloaded. Currently I either use the ctrl-click or just clear the quarantine bit from the terminal. I've not tried the sequoia beta to see if the latter still works but I'm assuming it does.

    • Re: (Score:3)

      by jythie ( 914043 )
      My understanding is 'yes', but the build system does it for you so it is transparent. I don't think i've ever triggered gatekeeper with anything I've compiled locally.

      • Exactly. The linker ad-hoc code signs, making the binaries good on the developerâ(TM)s machine.

        We explicitly disable automatic ad-hoc code signing in our builds. We do sign our builds separately and we set an environmental variable to control the signing identity. If you look at the codesign manpage, you can see that you can pass - (dash) as the identity to ad-hoc sign if necessary.

      • Which build system? For most of us using a cross-platform build system, such as make, you have to explicitly code the steps to sign the code, then run the notarizer. Documentation is sparse on how you do this - I had to spend a truly painful number of hours figuring out how to do it from Stack Overflow posts and the like. And then every few years, you have to do it again, when Apple changes the system (like they did last year). Also, these items have to run under a desktop, so you can't just build your soft

    • Yes, although the linker automatically ad-hoc code signs and makes this transparent.

  • Tempest in a teapot... (Score:5, Informative)

    by ctilsie242 ( 4841247 ) on Wednesday August 07, 2024 @06:28PM (#64689054)

    Overall, this is a good thing. I have not had to control-click an executable in years, and the only one I've had to bother with was WinRAR for Mac, which isn't GateKeeper signed. Adding it to an exeptions list isn't a big deal.

    If someone just wants to disable GateKeeper for good on a dev machine, run "sudo spctl --master-disable", and call it done. Or remove the extended attribute. [github.io]

    Is this a good thing? It is a bigger speedbump to protect against "dancing bunnies", where someone is told that if they want to see the dancing bunnies, they have to turn off a ton of security features. Forcing users to actually realize that they can't just walk into Mordor is important.

    I will miss the control item, but so few things actually use this, that this isn't a deal-breaker.

    Overall, it might be wise to run these items in a Docker container on the Mac, just so it fouls up stuff or spreads malware, it is limited to just one directory.

    • Is this a good thing? It is a bigger speedbump to protect against "dancing bunnies", where someone is told that if they want to see the dancing bunnies, they have to turn off a ton of security features. Forcing users to actually realize that they can't just walk into Mordor is important.

      All this means is that things like SameBoy [github.io], a Game Boy emulator for macOS, will end up distributed as an signed and notarized binary for $9.99 (to cover the developer's cost of renewing a Developer ID) or an unsigned binary without charge.

  • How? (Score:1)

    by The Cat ( 19816 )

    How can a user application be "malware" on a UNIX-like system without root privileges?

    Why can't the executable be run in a chroot container until it's verified? Then it wouldn't matter if it was malware.

    There was a wonderful program years ago called "Little Snitch" that popped up an alert if an application tried to open a network connection. Why isn't that a standard security application on all Macs (and iPhones for that matter) today?

    Meanwhile, shouldn't the default firewall settings on any iOS or OSX dev

    • Re:How? (Score:4, Informative)

      by innocent_white_lamb ( 151825 ) on Wednesday August 07, 2024 @07:43PM (#64689198)

      How can a user application be "malware" on a UNIX-like system without root privileges?
      ***
      Delete or encrypt your home directory.

      Delete or encrypt company data that you have access to.

      Run a background task under your username to do ghawd-knows-what. Password stealing or industrial espionage springs to mind.

      This is just what I thought of in the first three seconds after reading your question -- I'm sure there's lots more.

      • A signed app can be manipulated to do the exact same things, and more.

        If those kinds of issues are really important to you, you should have better redundancies and mitigations in-place. The GP's are some good starting recommendations for any system.

        • A signed app also gives you a developer identity, letting you know whom to sue through your affiliate in the appropriate country.

          • If you have money, you can pretty much buy any identity you want... or at least any identity with less money than you.

    • Re: (Score:2)

      by jythie ( 914043 )
      Anything you can do as a user, malware can do without needing to be root.

      • And anything the OS forbids in order to "protect" you from "malware" is something else they've forbidden you to do with hardware you bought and purchased.

  • I am still running Ventura, and contemplating upgrading to Sonoma. I have had too many bad experiences with Apple breaking my work environment with new upgrades. I'm in no hurry to upgrade. I use lots of software that Apple does not bless. If Sequoya is going to be a huge new pain, I may just stop at Sonoma.

    I don't need 'app signing.' I would rather NOT have the annoyance.

    Ask me again in a year, (or maybe two) and I'll reconsider it.

  • Actually, this is good! (Score:3)

    by williamyf ( 227051 ) on Wednesday August 07, 2024 @09:00PM (#64689322)

    In as much as it compels some lazy developers to sign and notarize their apps.

    I know there are some FOSS and/or passion projects from some developers (like Nareg Sinenian's excelent iSCSI initiator for MacOS https://github.com/iscsi-osx/i... [github.com] ) where is not feasible to sign and notarize their projects, but some other developers that could, just do not ccare....

    If this moves some of the lazy ones to do it, it is a good thing for us users.

    • Nah, I'm not giving money or PII to Apple. I'll just continue to not make osx builds, their loss. Lazy FTW!

  • ...take away more freedom
    Only those who pay the high tax will be allowed to play
    The enshittification continues

  • It's a sensible way to do things (Score:3)

    by battingly ( 5065477 ) on Wednesday August 07, 2024 @10:39PM (#64689432)
    I'm sure this change will trigger some people into thinking Apple is taking away their god-given freedom, but the notarization system works quite well. Any reputable app developer will sign/notarize apps, so if you come across an unsigned app, that's usually sign the app came from a sketchy source.

    • Suppose a university course in an Engineering or a CS department has students develop an app as a class assignment, and the other students are to review each others app by running it?

      Suppose an Engineering or a CS faculty member, gosh forbid, develops software to be run by students on MacOS?

      What is the cost to an academic institution for this signing?

      • The way the comments are worded in this thread, I feel like I'm listening to right-wing talk radio? What's the cost of a developer program license for an educational institution? Like 0.0000000000001% of what they pay the CEO.

        If anybody finds its financially or morally problematic to pay the nominal fee for an Apple developer account, they can distribute their software in source code format.

        • Your comment doesn't answer my question. What is the cost to an academic institution for this signing?

          At the U, our "CEO" makes a comfortable living, but her salary is orders of magnitude less than the CEO at a Fortune 500 corporation. If I counted your decimals correctly, 10^{-13} of our chancellor's salary would be on the order of a micropenny?

          There are things academic institutions spend money on, and there are things for which it is very difficult to spend money on at an academic institution becau

    • Its a little worse than some general mention of "freedom". This system calls home to Cupertino when you launch an app. This has been the case for some time, unfortunately [howtogeek.com] and is a big reason I moved away from MacOS- I am not OK with needing permission from the mothership to run a program on my computer.

      • Its a little worse than some general mention of "freedom". This system calls home to Cupertino when you launch an app. This has been the case for some time, unfortunately [howtogeek.com] and is a big reason I moved away from MacOS- I am not OK with needing permission from the mothership to run a program on my computer.

        In 2024 it is prudent to ask for some for some kind of authentication before you run an app on your computer. Authentication ultimately relies on a trust authority. If you're the unabomber running apps in a cabin in the woods off the grid and you don't believe in trust authorities, then you should simply set the system setting to permit the app to run.

    • Re: (Score:2)

      by tepples ( 727027 )

      Any reputable app developer will sign/notarize apps, so if you come across an unsigned app, that's usually sign the app came from a sketchy source.

      How does a hobbyist developer of free software typically cover the 99 USD cost of renewing their Developer ID each time it expires after 365 days?

      • Any reputable app developer will sign/notarize apps, so if you come across an unsigned app, that's usually sign the app came from a sketchy source.

        How does a hobbyist developer of free software typically cover the 99 USD cost of renewing their Developer ID each time it expires after 365 days?

        If you're running in-house software or your own software, just set the system setting to permit your app to run. The way people are bending over backwards to invent some kind of controversy over this is hilarious.

        • Re: (Score:2)

          by tepples ( 727027 )

          I'm referring to a hobbyist developer of free software used by other people. The one that comes to mind is SameBoy, a Game Boy emulator for macOS developed by Lior Halphon.

  • any sane person who advocates for freedom in general-purpose computing should or should have switched to GNU/Linux. I know I did. I don't care that it's hard to use, or that it has issues with some drivers, or that there are thousands of distros/desktop environments to choose from. I just want to do general-purpose computing without ads or walled gardens
    • It's not really that hard to use, tbh. For comparison, the guy in the thread above was talking about using xattr to change an extended attribute on OSX.
  • Soon to be thought of as "subversives" and finally "criminals". MacOS security (against the owner) to follow. The water the frog is sitting in got a little warmer...
  • And with the next version you can only run apps downloaded from the macstore.

  • I mean letting people run code on their machines kinda is a security bug, after all I wouldn't run anybody else to run their code on my computer. So I can fully understand that Apple doesn't want just anybody to run their code on Apple's machines.

    However, since the users pay a fee to have Apple's computers on their desks, one might argue that the users have at least some share in the ownership of Apple's computers, however I am not sure if there is any legal base for this. After all, Apple is one of the com

  • I generally think for the average user this is a pretty useful security feature and I love having the option in OS X and macOS for many years!

    Is there an equivalent option for Windos? Equally easy to enable and use, without crazy complex group policies and maintaining good/bad lists?

  • Fuck Apple. And fuck Steve Jobs for resurrecting them when they were at the point of death.

Slashdot Top Deals

Technology is dominated by those who manage what they do not understand.

Close