Hacker News Reader

Comment by JohnMakin | Hacker News Reader

I wanted to leave the original post unsullied by my ragy commentary:

They are listing this as "operational" but the steps they are outlining here are not a proper solution for this problem! I cannot sudo on my work macs. How can a severe problem like this go on for more than a week? This has completely shut down my local development. I'm mad at the situation more than anything, but also a big middle finger to mac OS for not allowing me, a somewhat mature professional adult with expertise in stuff like this, what I want on my machine. My new workstation orders are not going to be macs. Good job!

The worst part is, even if you go with the extremely user-hostile un-minimizable prompt wants you to do, which is delete a bunch of files, the popup will still spam you until you are able to follow the instructions on the remediation that docker provided! Completely FUBAR

View on HN

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.

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

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.

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.

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/

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.

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

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/

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.

Not having sudo on a work managed mac is so completely common that I struggle to take anyone seriously that argues otherwise and I'll just leave that comment here

My sample of 3 shows the Macs in big corp has some way to temporary get sudo. Some sort of proprietary app you run that grants you permissions for a period of time. Sometimes there is a text field for "reason", but no one ever reads it.

A work managed mac without a sort of helpdesk that can help you fix an update issue of approved software is equally unserious.

I have never had sudo on a work managed device, but always had a phone number to call for exactly these types of issues. Explain the problem, point them to the fix. They look it up internally, call me back half an hour later, take over the machine and perform the procedure.

Is it frictionless? No. Is it impossible? No, just part of dealing with corporate IT.

Imagine I am the corporate IT here. I don’t even need docker desktop! I’m switching to something else. This is now a huge unnecessary pain that still has yet to be explained.

John, it's really pretty easy to fix:

Take a deep breath.

Uninstall docker, including from homebrew if you've ever used that to install it.

Reboot

Download newest ARM version from Docker.

Install it.

Reboot again.

You should be good.

If it wasn’t clear in my original post, I have to solve this for a fleet of machines. I’ve taken many breaths today, but thanks for your condescending concern. And as I said, for people with typical machine access in an org, this is a completely unacceptable solution. Anything that requires sudo access and a pasted bash script in a doc is a completely unacceptable solution. You cannot turn around and call this solved.

What you can do is have a cron job that continuously polls one or more URLs looking for tarballs with Git repos accompanied by GnuPG or Signify signatures. The primary idea is that the tarballs are only unpacked and executed if the signatures are valid and anything received by the machines is only executed after the hashes and signatures are successfully logged, this prevents (or at least documents) any abuse on the part of the IT team. Inside the tarballs are Salt, Ansible, and/or shell commands.

In addition to a cron job, we had an active pubsub listener on each machine to poke this process.

You can do this on macOS too, or at least, modern macOS "should" be able to do this.

We did this on a large fleet of user machines (laptops) running Windows 10/11, macOS, and Linux.

On an entirely separate tangent... Why are you remotely managing macs? That seems like a cluster of nightmarish proportions without even getting to this issue.

If you don't trust people, give them Windows and use the tools that have been around for decades for this.

Remote management is a requirement for SOC other compliance frameworks.

That doesn’t sound right. Most of SOC compliance boils down to having a plan to check enterprisey checkboxes.

So, you pay someone that can write a report explaining how the boxes will be checked in a way that minimizes the blast radius of security theater stuff like broken approaches to remote management. Consider fixing your soc compliance plan.

Anyway, assuming the remote management tool has root, you can use brew to install docker desktop from the cli.

In principle yes. The implementation however is rarely defined (if you have examples, feel free to share). In my experience it's by choice that companies use compliance to turn their dev environments into a micromanaged hell that engineers hate working in (our company went through multiple compliance certifications including SOC1 and SOC2).

Not at the level John was talking about. My last company had SOC 2 and yes, there was remote management, but the developers still had admin access to their machines, and didn't need some BOFH to use docker.

I agree that requiring sudo access may not work for some orgs at a user level. But it also seems unusual that you need to solve this for a fleet of machines and yet are not allowed sudo access.

I dont know how it could be less obvious that I manage other users’ devices, and yes, I can escalate my permissions fine, but rolling this out to a distributed fleet of machines, some of which may not be remotely in the same timezone, is not quite as easy - there are many situations where sudo is not granted by default to a workstation. I’m amazed people find this surprising in this thread.

If you're managing Macs on anything like an official basis, why are you not using any of the various tools that exist to enable and streamline that?

Macs have built-in device management tools, and there are third-party solutions like JAMF that can definitely run scripts like what's needed to fix Docker, as root, including reboots if necessary.

It really sounds like the primary problem you're experiencing is not what Macs allow, nor even the shoddiness of the Docker solution (which I will not attempt to defend, I agree they should have something more robust), but your company's policies that put you in a position of responsibility but no power.

sometimes you deal with contractors that you don’t have such explicit and unrestricted access to their devices. but yes, being in a position of responsibility and no power is basically the IT sysadmin’s creed, and that is not even my official role, just one I am forced to play a lot.

And this is a problem with company policies, not with the design of macOS or Docker.

I'm sorry, but there's just no sane system design that can make up for such abjectly counterproductive policies, no matter how common they may be.

If you are in the org with managed macs, you should not be doing this yourself, your IT (or security, or whomever manages your computer) should be creating a script and adding it to whatever secure script runner they deployed to user machines. Or even better, automatically fixing this.

If you are in the org where your IT cannot do this, and the same IT took away your "sudo" access, then there is nothing you can do. Even if there were a hacky way, it would be against policies, so do it by the book and wait for IT to fix it for you. If you are on important and urgent project, escalate via official channels. If you are not on important project, relax and don't forget to write "I could not do anything because I am blocked on IT" in all of your status reports.

If the previous paragraph makes your blood boil or makes you want to cry, consider working for a different company which either gives autonomy to developers or has better IT.

I have literally switched to a lower paying job because of IT issues at a previous firm. The extra headaches was not worth it to me. It doesn't help IT was full of Microsoft fanboys over there who saw Macs as a nuisance and did barely any testing on them of their updates

> should be creating a script and adding it to whatever secure script runner they deployed to user machines. Or even better, automatically fixing this.

It may surprise you to learn that a lot of orgs have critically understaffed or unknowledgeable IT teams. Yea, I could "solve" world hunger by simply feeding everyone, but how do I actually do that?

I am the crititcally understaffed "IT" that has to fix it for you. And now it's urgent because local development has basically halted on tons of devices for a variety of weird and undocumented reasons. I am trying to communicate to you that rolling out a "fix" for this type of thing to a distributed fleet is not trivial at all. For a typical IT sysadmin this is one of the most annoying possible things, at the worst possible time too (post holiday), and that's not even my official role! I just have to play it a lot. Also, I think you're severely underestimating how complicated it is managing a remote fleet of devices under current compliance and security standards across the industry. You're talking from the perspective of a dev that gets mad they can't have unlimited access to the prod db with a single ticket, I think, but the reality is these things are not easy to roll out on the fly under specific circumstances. Good for you that you found a company that fits your needs/whims and isnt bound by these same kinds of restrictions. I'm also not making any commentary on whether any of this is sane at all, just that I am the guy at the short end of the stick that has to deal with it and I'm (justifiably) pissed off about it.

used to have a gig where local dev worked on all machines except mine lol if it is only broken when Docker messes up horrible but not the worst it could be if perspective helps in this situation :)

Turn off updates, test things first

Reply on news.ycombinator.com