Hacker News

points by brookst 1 day ago | 0 comments

I don't know about worse. Imagine a world where there is no OS authority, each app does their own. Do you think all important apps would be updated in 10 days, including auto-updates?

Apple fucked this up, but I really don't think the situation is "as bad if not worse" than if MacOS just didn't do this.

[–] mikepurvis 1 day ago

Isn't that the world that Docker gives us, basically?

[–] Shish2k 1 day ago

Yes - difficulty in shipping security updates to a hundred different container images, each of which is vulnerable in their own slightly-different way because they all decided to ship an OS alongside their app - is one of the top criticisms of the docker way of doing things

[–] stephbook 1 day ago

Just run it in kubernetes and mount the certificates with trust-manager

[–] paulddraper 1 day ago

> just

> kubernetes

[–] gchamonlive 6 hours ago

If it were 5 years ago I'd have the same reaction, but today it's fairly simple to setup a single node deployment with minikube or k3s, and LLM makes it very easy to maintain deployments.

[–] musicale 1 day ago

> docker

If only we could somehow share libraries and configuration files across apps rather than duplicating them and having to update them for every app individually.

We could call it a "shared library" system and an "operating" system. Someone should really invent this.

I mean, even docker could maybe use a shared base image or something right? ;-)

[–] mixedCase 1 day ago

Now make it immutable and layered, like Docker images, and you might be onto something... Ah well, sounds too good to be true. We might have to nix the idea.

[–] mikepurvis 15 hours ago

Should it also predate Docker by a decade? That would be crazy.

[–] xp84 1 day ago

What kind of psychopath ships 100 distinct container images? I mean, maybe if you’re talking about all of Netflix or something, but… I suspect even they have base images that they use as a starting point.

There’s very little actually running in a docker container. ca-certs may actually be an exceptional case though, since it’s not code that’s running but a kind of data.

It’s not like if you use an Ubuntu image for a node.js app that you get PHP too and have the PHP vulnerability present in your web app.

[–] stackskipton 1 day ago

You still have to rebuild each Application Container with new CACert and deploy them. Depending on teams are working, that can be disruptive.

[–] anamexis 1 day ago

I would say that if rebuilding your docker containers is a disruptive process, that is a process issue.

[–] stackskipton 1 day ago

I would agree but it doesn't change the fact that many companies do not have CD and have processes that must be followed for rollouts.

It's same problem we have when libraries get massive security vulnerabilities. Updating them is not always as easy as many would like.

[–] mikepurvis 12 hours ago

I think the number one thing that bites a lot of container workflows is when you have a separate "base image" build that depends on external, mutable package sources using tools that don't support locking, such as apt.

This gets worse for each additional such layer, for example if you start from ubuntu:whatever and have a system deps layer, then an application deps layer, then static assets, then your app's code. Unless you think about it upfront when designing the pipeline, it can be challenging to trace all that state backwards and figure out how to safely re-build thing-from-x-weeks ago but with a single unsafe package bumped forward.

Every shop with competent devops people present should be set up for this, but it usually doesn't come for free.

[–] GoblinSlayer 22 hours ago

AFAIK a container build just puts files into a base image, this creates a sort of a commit chained to the base image commit. This means to update the base image you only need to rebase that commit on top of the new base image branch automatically.

[–] notpushkin 19 hours ago

I haven’t seen tooling for rebasing OCI images yet. Considering you’d still have to do this and roll it out to the server, you can just re-run the CI, which would build the image again, but also test that it works with the new base image.

[–] lakeviewterrace 1 day ago

> Imagine a world where there is no OS authority, each app does their own.

That's the world we live in now thanks to Google and Mozilla.

[–] emn13 21 hours ago

Surely there's a nuanced difference between "every app distributes this independently" and "a very small few apps that bear the brunt of hostile exposure support independent mechanisms".

It's also worth remembering that both of these specific organizations were instrumental in major, positive security shifts that eventually hit OS's too, including shorter-lived certs, limiting the point of CAs, adoption of TLS 1.3, and likely other things. If anything, they deserve _more_ trust than the OS distributors on this specific front, perhaps also because they don't share the OS distributor's incentive to prioritize stability for paying customers, which can be at odds at times with harsh, prompt security measures.

[–] musicale 1 day ago

> Apple fucked this up, but I really don't think the situation is "as bad if not worse" than if MacOS just didn't do this.

https://support.apple.com/en-us/149555

[–] gchamonlive 1 day ago

It makes no sense to imagine this hypothetical scenario and compare it to reality, you have to imagine a similar world with a OS authority, but it only gets updated every 6 months. Which is worse in the worse case? I'd say the one with the lower blast radius.

But this abstract exercise is only to highlight the importance of Apple getting its shit together, because such a scenario exists with Windows and the culture of downloading exes and msis and it's honestly way worse than having a central but responsible authority.