5 ms·

Anything you compile on your own system you can run. This only affects downloaded binaries.

by adastra22 2y ago

IshKebab 2y ago
Thanks for confirming the nightmare.
- steve_adams_86 2y ago
  I mean, you can download source if you want to run it. It isn’t a complete nightmare yet. I think we’re still in a grey area. This will help some people still, though it’ll definitely hinder others (myself included). Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet.
  - skrrtww 2y ago
    > Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet. This is the case for building and running things with restricted entitlements and system extensions. Unless you disable system integrity protection entirely, which locks you out of your purchased App Store software, DRM content, etc.
    - adastra22 2y ago
      You can no longer disable system integrity protection.
      - NotPractical 2y ago
        Source?
        adastra22 2y ago
        The release notes for Sequoia.
        sbuk 2y ago
        Nope. Not the enterprise release notes or the security content notes either.
        adastra22 2y ago
        What I'm referencing is that they removed `spctl --master-disable`. This was referenced in release notes that I read upon upgrading, and testing it on my own system confirms it is gone. Looks like there might be a way of achieving the same thing through the GUI? https://www.reddit.com/r/MacOSBeta/comments/1e2xlcg/disabling_gatekeeper_on_macos_sequoia_beta_3_has/ https://www.reddit.com/r/MacOSBeta/comments/1e2xlcg/disablin...
        NotPractical 2y ago
        That's Gatekeeper, not System Integrity Protection. You can disable SIP with `csrutil` by rebooting into the macOS recovery environment.
      - pcwalton 2y ago
        You can [1]. [1]: https://www.reddit.com/r/hackintosh/comments/1fh5wez/cant_disable_sip_in_sequoia/ https://www.reddit.com/r/hackintosh/comments/1fh5wez/cant_di...
    - dur-randir 2y ago
      >which locks you out of your purchased App Store software, DRM content Also false. But Apple's glad you believe in that.
      - skrrtww 2y ago
        I was mistaken; I was conflating Permissive Security with SIP. Permissive Security does have those limitations.
      - NotPractical 2y ago
        It does lock you out of iOS apps, Apple Pay, and 4K streaming of DRM content [1]. But that's not so bad I suppose. [1] https://github.com/cormiertyshawn895/RecordingIndicatorUtility?tab=readme-ov-file#troubleshooting-tips https://github.com/cormiertyshawn895/RecordingIndicatorUtili...
  - ryandrake 2y ago
    > Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet. When Quarantine was released in Leopard, and Gatekeeper in Lion, and System Integrity Protection in El Capitan, and then "Allow from Anywhere" was removed as an option in Sierra... Each time, people were saying similar things. "Yea, it's bad, and it's getting consistently worse with every release, but surely we are nowhere near 'really bad' yet!"
    - adastra22 2y ago
      To me these are clear security improvements; things are not getting worse. And there is absolutely no reason to think they'll be dropping support for endusers running their own compiled software.
      - int_19h 2y ago
        The obvious end point would be the same as iOS, which is to say - you can run it to your heart's content, provided that you shell out for a dev certificate.
        adastra22 2y ago
        That is not at all obvious.
        IshKebab 2y ago
        It's very obvious if you're paying attention. What is the security benefit of removing the command-click shortcut?
        tpmoney 2y ago
        One argument in favor of removing it (not saying it’s the reason or that they didn’t have other options) is that ctrl-click and open did not obviously do anything different. That is, whether you ctrl-click and open a signed app or an unsigned app, the command in the menu was just “open”, with no indication that you were overriding a security policy. Then the dialog it popped up wasn’t particularly distinct from the “first time run” dialog. There is an argument to be made that going to the security settings and specifically allowing an app is a more clear expression of intent. Kind of in the same way you probably want to open a file you download from the web, but good security practices means the browser doesn’t open it for you on download, you need to explicitly go do it. That said there’s no reason they couldn’t have fixed either of those issues instead
- adastra22 2y ago
  Care to explain the nightmare to someone who seriously doesn't get it? I can run any open-source software I want. Other people can't run my precompiled binaries unless I opt into an attestation system that lets the OS respond to and pre-emptively block binaries from developers found to be issuing malware. Open source is unaffected. I seriously fail to see what is wrong here.
  - int_19h 2y ago
    That would kill a lot of old software, though. Especially games.
    - adastra22 2y ago
      I challenge you to find old software that still runs on modern Macs which was never code signed. Note that support for 32-bit applications has been retired, and x86 applications will eventually be sunsetted as well. This isn't Windows.
      - int_19h 2y ago
        Indeed, the current state of affairs on the Mac is the consequence of Apple repeatedly making this kind of choice. That doesn't make it any less frustrating when things that worked before, stop working after.
chongli 2y ago
Yes, so we should move to a source-based package manager and build system, like FreeBSD ports.
- adastra22 2y ago
  There are plenty of options for that on macOS, the most common being homebrew and MacPorts.
  - Hamuko 2y ago
    Homebrew defaults to downloading binaries.
    - adastra22 2y ago
      Defaults to. You can tell it to compile yourself, if that matters to you. I don’t see what the issue is here. Why is it a problem that it defaults to binary distribution?
      - Hamuko 2y ago
        The biggest problem is that the defaulting to binary distribution also means that building from source is unsupported. >Building from source takes a long time, is prone to failure, and is not supported. Having issues building your Homebrew packages from source? Well, you better not take it to the bug tracker.
        fredoliveira 2y ago
        > The biggest problem is that the defaulting to binary distribution also means that building from source is unsupported. I don't think it means that at all. They're both clearly supported by homebrew — one just happens to be the default. You can always use -s or --build-from-source to build whatever package you are installing.
        2y ago

Anything you compile on your own system you can run. This only affects downloaded binaries.

IshKebab 2y ago

Thanks for confirming the nightmare.

steve_adams_86 2y ago
I mean, you can download source if you want to run it. It isn’t a complete nightmare yet. I think we’re still in a grey area. This will help some people still, though it’ll definitely hinder others (myself included). Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet.
- skrrtww 2y ago
  > Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet. This is the case for building and running things with restricted entitlements and system extensions. Unless you disable system integrity protection entirely, which locks you out of your purchased App Store software, DRM content, etc.
  - adastra22 2y ago
    You can no longer disable system integrity protection.
    - NotPractical 2y ago
      Source?
      - adastra22 2y ago
        The release notes for Sequoia.
        sbuk 2y ago
        Nope. Not the enterprise release notes or the security content notes either.
        adastra22 2y ago
        What I'm referencing is that they removed `spctl --master-disable`. This was referenced in release notes that I read upon upgrading, and testing it on my own system confirms it is gone. Looks like there might be a way of achieving the same thing through the GUI? https://www.reddit.com/r/MacOSBeta/comments/1e2xlcg/disabling_gatekeeper_on_macos_sequoia_beta_3_has/ https://www.reddit.com/r/MacOSBeta/comments/1e2xlcg/disablin...
        NotPractical 2y ago
        That's Gatekeeper, not System Integrity Protection. You can disable SIP with `csrutil` by rebooting into the macOS recovery environment.
    - pcwalton 2y ago
      You can [1]. [1]: https://www.reddit.com/r/hackintosh/comments/1fh5wez/cant_disable_sip_in_sequoia/ https://www.reddit.com/r/hackintosh/comments/1fh5wez/cant_di...
  - dur-randir 2y ago
    >which locks you out of your purchased App Store software, DRM content Also false. But Apple's glad you believe in that.
    - skrrtww 2y ago
      I was mistaken; I was conflating Permissive Security with SIP. Permissive Security does have those limitations.
    - NotPractical 2y ago
      It does lock you out of iOS apps, Apple Pay, and 4K streaming of DRM content [1]. But that's not so bad I suppose. [1] https://github.com/cormiertyshawn895/RecordingIndicatorUtility?tab=readme-ov-file#troubleshooting-tips https://github.com/cormiertyshawn895/RecordingIndicatorUtili...
- ryandrake 2y ago
  > Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet. When Quarantine was released in Leopard, and Gatekeeper in Lion, and System Integrity Protection in El Capitan, and then "Allow from Anywhere" was removed as an option in Sierra... Each time, people were saying similar things. "Yea, it's bad, and it's getting consistently worse with every release, but surely we are nowhere near 'really bad' yet!"
  - adastra22 2y ago
    To me these are clear security improvements; things are not getting worse. And there is absolutely no reason to think they'll be dropping support for endusers running their own compiled software.
    - int_19h 2y ago
      The obvious end point would be the same as iOS, which is to say - you can run it to your heart's content, provided that you shell out for a dev certificate.
      - adastra22 2y ago
        That is not at all obvious.
        IshKebab 2y ago
        It's very obvious if you're paying attention. What is the security benefit of removing the command-click shortcut?
        tpmoney 2y ago
        One argument in favor of removing it (not saying it’s the reason or that they didn’t have other options) is that ctrl-click and open did not obviously do anything different. That is, whether you ctrl-click and open a signed app or an unsigned app, the command in the menu was just “open”, with no indication that you were overriding a security policy. Then the dialog it popped up wasn’t particularly distinct from the “first time run” dialog. There is an argument to be made that going to the security settings and specifically allowing an app is a more clear expression of intent. Kind of in the same way you probably want to open a file you download from the web, but good security practices means the browser doesn’t open it for you on download, you need to explicitly go do it. That said there’s no reason they couldn’t have fixed either of those issues instead
adastra22 2y ago
Care to explain the nightmare to someone who seriously doesn't get it? I can run any open-source software I want. Other people can't run my precompiled binaries unless I opt into an attestation system that lets the OS respond to and pre-emptively block binaries from developers found to be issuing malware. Open source is unaffected. I seriously fail to see what is wrong here.
- int_19h 2y ago
  That would kill a lot of old software, though. Especially games.
  - adastra22 2y ago
    I challenge you to find old software that still runs on modern Macs which was never code signed. Note that support for 32-bit applications has been retired, and x86 applications will eventually be sunsetted as well. This isn't Windows.
    - int_19h 2y ago
      Indeed, the current state of affairs on the Mac is the consequence of Apple repeatedly making this kind of choice. That doesn't make it any less frustrating when things that worked before, stop working after.

chongli 2y ago

Yes, so we should move to a source-based package manager and build system, like FreeBSD ports.

adastra22 2y ago
There are plenty of options for that on macOS, the most common being homebrew and MacPorts.
- Hamuko 2y ago
  Homebrew defaults to downloading binaries.
  - adastra22 2y ago
    Defaults to. You can tell it to compile yourself, if that matters to you. I don’t see what the issue is here. Why is it a problem that it defaults to binary distribution?
    - Hamuko 2y ago
      The biggest problem is that the defaulting to binary distribution also means that building from source is unsupported. >Building from source takes a long time, is prone to failure, and is not supported. Having issues building your Homebrew packages from source? Well, you better not take it to the bug tracker.
      - fredoliveira 2y ago
        > The biggest problem is that the defaulting to binary distribution also means that building from source is unsupported. I don't think it means that at all. They're both clearly supported by homebrew — one just happens to be the default. You can always use -s or --build-from-source to build whatever package you are installing.
        2y ago