4 ms·

Judging from the fact that all the workaround does is reinstall a privileged daemon, you needed root to install Docker in the first place. Why are you outraged

Judging from the fact that all the workaround does is reinstall a privileged daemon, you needed root to install Docker in the first place. Why are you outraged that you need root again to reinstall? Moreover, how is that even a macOS problem? Being outraged that you need to invoke administrative privileges on a development machine seems unreasonable to me. You can't get far with that kind of restriction.

JohnMakin 2y ago
because modern macOs does not gracefully allow true root, without hacking, in a way that doesnt solve compliance requirements?
- soraminazuki 2y ago
  macOS obviously has the capability to reinstall Docker. If your company is preventing you from upgrading to the fixed version in timely manner, that's your company's responsibility.
  - JohnMakin 2y ago
    Perhaps you should inform yourself about the actual problem/proposed solution here - the issue isnt installing a fresh new version, it’s the uninstallation steps required to even get there in the first place. and no, mac os will not let me do this, even when I follow the prompts. docker’s elevated permission scripted solution is the only thing that has worked yet.
    - soraminazuki 2y ago
      Looking at the incident page, the bash solution was superseded by a proper release the next day. And the linked document specifically instructs to "update directly through the app" if possible [1]. So uninstall not working is completely news for most people reading this thread. Even the title of this thread, "Docker Desktop Broken on Mac OS Update for over a Week," isn't substantiated anywhere else. But even if it is required to manually stop and remove the two daemons, shouldn't that be doable using any device management solution? Perhaps using something like Jamf Self Service? Because it otherwise wouldn't be possible to deploy any changes without that kind of capability. [1]: https://docs.docker.com/desktop/cert-revoke-solution/ https://docs.docker.com/desktop/cert-revoke-solution/
      - JohnMakin 2y ago
        Their proposed solution didn't work on many of my fleet's devices. I had to go deep into a reddit thread + stackoverflow comment to figure out a proper mitigation for several devices, and it involved extremely invasive/terrible things to remediate. Their fix doesn't even work for everyone, and they're clearly prioritizing paying customers for that kind of support. Like, fine, but don't publish a status that says "operational" when your "fix" is so slipshod as this. Just absolutely embarrassing, in my candid opinion. I know enough to fix this on any device but it isnt just a singular problem local to myself, and they haven't exactly been communicative about the root cause or very helpful to anyone that isn't paying them a lot of money. Like, I understand its "open" source "free"ware and YMMV there, but this kind of thing is entirely preventable most likely. There are so many viable alternatives to docker desktop that this has finally made me jump ship. There's no possible way this isn't a sinking ship, in my opinion. The writing has been on the wall for a while.
int0x29 2y ago
Company zero trust policies can make that impossible. In such cases you can reinstall official approved releases but not manually sudo random things
- soraminazuki 2y ago
  I'm aware that some companies implement that kind of security policy. But that makes it the company's job to make sure fixes for software critical to development are rolled out in a timely fashion. The way the OP is raging at everybody except their own company is totally unreasonable. Also, disallowing root is developer hostile security theater IMO. It prevents a wide range of debugging techniques while being limited in the kind of harm it prevents. Obligatory XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - JohnMakin 2y ago
    It’s theater but any heavily audited environment will have compliance requirements like this. It is unreasonable to blame the person implementing the requirements as if it’s their fault the compliance stipulations exist. and even then it’s completely reasonable to disallow unlimited privileges on a managed workstation. the first time you deal with a breach because some idiot developer decided to install malware masquerading as a chatgpt wrapper will teach you this lesson.

JohnMakin 2y ago

because modern macOs does not gracefully allow true root, without hacking, in a way that doesnt solve compliance requirements?

soraminazuki 2y ago
macOS obviously has the capability to reinstall Docker. If your company is preventing you from upgrading to the fixed version in timely manner, that's your company's responsibility.
- JohnMakin 2y ago
  Perhaps you should inform yourself about the actual problem/proposed solution here - the issue isnt installing a fresh new version, it’s the uninstallation steps required to even get there in the first place. and no, mac os will not let me do this, even when I follow the prompts. docker’s elevated permission scripted solution is the only thing that has worked yet.
  - soraminazuki 2y ago
    Looking at the incident page, the bash solution was superseded by a proper release the next day. And the linked document specifically instructs to "update directly through the app" if possible [1]. So uninstall not working is completely news for most people reading this thread. Even the title of this thread, "Docker Desktop Broken on Mac OS Update for over a Week," isn't substantiated anywhere else. But even if it is required to manually stop and remove the two daemons, shouldn't that be doable using any device management solution? Perhaps using something like Jamf Self Service? Because it otherwise wouldn't be possible to deploy any changes without that kind of capability. [1]: https://docs.docker.com/desktop/cert-revoke-solution/ https://docs.docker.com/desktop/cert-revoke-solution/
    - JohnMakin 2y ago
      Their proposed solution didn't work on many of my fleet's devices. I had to go deep into a reddit thread + stackoverflow comment to figure out a proper mitigation for several devices, and it involved extremely invasive/terrible things to remediate. Their fix doesn't even work for everyone, and they're clearly prioritizing paying customers for that kind of support. Like, fine, but don't publish a status that says "operational" when your "fix" is so slipshod as this. Just absolutely embarrassing, in my candid opinion. I know enough to fix this on any device but it isnt just a singular problem local to myself, and they haven't exactly been communicative about the root cause or very helpful to anyone that isn't paying them a lot of money. Like, I understand its "open" source "free"ware and YMMV there, but this kind of thing is entirely preventable most likely. There are so many viable alternatives to docker desktop that this has finally made me jump ship. There's no possible way this isn't a sinking ship, in my opinion. The writing has been on the wall for a while.

int0x29 2y ago

Company zero trust policies can make that impossible. In such cases you can reinstall official approved releases but not manually sudo random things

soraminazuki 2y ago
I'm aware that some companies implement that kind of security policy. But that makes it the company's job to make sure fixes for software critical to development are rolled out in a timely fashion. The way the OP is raging at everybody except their own company is totally unreasonable. Also, disallowing root is developer hostile security theater IMO. It prevents a wide range of debugging techniques while being limited in the kind of harm it prevents. Obligatory XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- JohnMakin 2y ago
  It’s theater but any heavily audited environment will have compliance requirements like this. It is unreasonable to blame the person implementing the requirements as if it’s their fault the compliance stipulations exist. and even then it’s completely reasonable to disallow unlimited privileges on a managed workstation. the first time you deal with a breach because some idiot developer decided to install malware masquerading as a chatgpt wrapper will teach you this lesson.