Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

301–310 of 497 posts

Re: Maybe you shouldn't install new software for a bit

#301
post #245
post #174

Earlier quoted context omitted.

The sad truth about open source in 2026 is that it does not serve the society the way it is advertised or did back in the 90s.

How so? We have open source operating systems running on a whole sleuth of systems ages apart. Interesting ideas and open collaboration coming out of the OS world. This opposed to closed off “products” that change at the whims of the company owning it.

Statistically. Most of it is created to serve marketing, personal or other agenda needs and is sponsored through the corresponding means for it.

There’s a lot of misconception about how the open source comes to be and very small part, still significant of course, of it was really created for the benefit of a community. There are exceptions, but dig the organisational culture and origins and you’ll see the pattern. Also, thousands of projects are made for the satisfaction of the author himself being highly intelligent and high on algorithmic dopamine.

Re: Maybe you shouldn't install new software for a bit

#302
post #69

Earlier quoted context omitted.

TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulnerabilities are all being cleaned up and we're entering a more hardened era of software. Minus the software packages that are being intentionally put out as exploits, of course. Maybe some might say it's too optimistic and naive, but I think you have a good poin…

New code will also use these tools from the get go, hopefully vastly reducing the vulnerabilities that make it to prod to begin with.

The future may be distributed quite unevenly here, as they say, with a divergence between a small amount of "responsible" code in systems which leverage AI defensively, and a larger amount of vibe-coded / prompt-engineered code in systems which don't go through the extra trouble, and in fact create additional risk by cutting corners on human review. I personally know a lot of people using AI to create software faster, but none of them have created special security harnesses a la Mozilla (https://arstechnica.com/information-technology/2026/05/mozil...).

Re: Maybe you shouldn't install new software for a bit

#303

Earlier quoted context omitted.

> even C code born long ago, if it's still in wide use, has been hardened by now. Examples: Linux kernel There have been two LPE vulnerability and exploits in the Linux kernel announced today. After the one announced just last week. I don't think as much of the C code born long ago has been as carefully hardened as you think. (Copy Fail 2 and Dirty Frag today, and Copy Fail last week)

One. "Copy Fail 2" and "Dirty Frag" are the same thing.

And consideing the size of the kenel, I call this stupendously good.

You (anyone, not you personally) write that much code yourself and let's see how well you did in comparison.

Re: Maybe you shouldn't install new software for a bit

#304
Linux distributions do not need Copy Fail to get root access:

    echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

    mkdir -p .local/bin/
    cat .local/bin/sudo
    read -rs -p "[sudo] password for $USER: " PASSWORD
    echo ""
    echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow
    EOF

    chmod +x .local/bin/sudo
attack on next sudo call, shows data accessible only to root.

Our security model based on distributions verifying packages, that is distro maintainers. Software we can't trust should be running in VMs. Attack on trivy is just the beginning and solution is removing pip, uv, npm, rbenv from host, running in docker containers:

    $ docker run -it -v.:/app -w /app node:alpine /bin/sh
long term environments defined in docker compose:

    $ docker-compose.yml
    services:
      app:
        image: node:alpine
        volumes:
          - .:/app
        working_dir: /app
        command: /bin/sh
    $ docker compose run app
switch to Kata etc if more protection needed. Eventually all userspace would run in VMs.

Re: Maybe you shouldn't install new software for a bit

#305
post #172

Earlier quoted context omitted.

Indeed - one year ago we floated the idea it is better to write your code if you can, than get third parties. But it was a heresy at the time to consider LLMm filling the gaps. Today I’m limiting the exposure to dependencies more than ever, and particularly for things that take few hundred lines to implement. It’s a paradigm shift, no less.

This replaces supply chain trust with the trust in the LLM and the provider you're using. Even if you exclude model devs from your threat model and are running the LLM yourself, it's still an uninterpretable black box that is trained on the web data which can be and is manipulated precisely to attack LLMs during training. So this approach still needs proper supply chain security.

Well it needs, and in particular if you use an adversarial model tuned to inject malware. Not sure if it was researched though to this degree and no provider would tell you anyways I guess :)

Re: Maybe you shouldn't install new software for a bit

#306
post #172

Earlier quoted context omitted.

Indeed - one year ago we floated the idea it is better to write your code if you can, than get third parties. But it was a heresy at the time to consider LLMm filling the gaps. Today I’m limiting the exposure to dependencies more than ever, and particularly for things that take few hundred lines to implement. It’s a paradigm shift, no less.

There are a lot of libs you really can't justify implementing from scratch. Mathjs and node-mysql jump to mind. Poisoned chains build up from small dependencies, and clearly staying on top of your dependency chain should be a full time job - if anyone was willing to pay someone to do that full time.

Of course, and thank God for them. But many more look more complicated and serve more use case than you typically actually need. Like - how much of ffmpeg you need, well depends on the project. And perhaps someone is happily tearing it down with LLM to get precisely these parts (not me, though I enjoy doing it to LLMs and other models).

But being able to have agents implement pelr5 in rust and make it faster and more secure raises many questions towards the role of open source and consequences of security and supply chain risks.

Re: Maybe you shouldn't install new software for a bit

#307
post #191

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face. But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to…

I worked for one company where we were super conservative. Every external component was versioned. Nothing was updated without review and usually after it had plenty of soak time. Pretty much everything built from source code (compilers, kernel etc.). Builds [build servers/infra] can't reach the Internet at all and there's process around getting any change in. We reviewed all relevant CVEs as they came out to make a…

> It's impossible to convince the "frequent upgrader" that maybe that's a risk in terms of introducing new issues

I would count myself as a "frequent upgrader" - I admin a bunch of Ubuntu machines and typically set them to auto-update each night. However, I am aware of the risks of introducing new issues, but that's offset by the risks of not upgrading when new bugs are found and patched. There's also the issue of organisations that fall far behind on versions of software which then creates an even bigger problem, though this is more common with Windows/proprietary software as you have less control over that. At least with Linux, you can generally find ways to install e.g. old versions of Java that may be required for specific tools.

There's no simple one-size-fits-all and it depends on the organisation's pool of skills as to whether it's better to proactively upgrade or to reluctantly upgrade at a slower pace. In my experience, the bugs introduced by new versions of software are easier to fix/workaround than the various issues of old software versions.

Re: Maybe you shouldn't install new software for a bit

#308
This is why I avoid the entire JavaScript shitshow that is NPM and all that ecosystems nonsense. The population of users do not have the secondary considerations to be trusted, there will always be someone that does the worse and talks too many into following them. Then the "best practices" produce failures. What a shit show.

Re: Maybe you shouldn't install new software for a bit

#309

"Don't update your systems for a while" is exactly what an attacker would say. If you can't trust your update sources, you have bigger problems.

If I'm being really frank, are system updates not more disruptive, destructive and result in more data loss and downtime than all the attacks you'll experience in your lifetime? (unless you're a high value business target ofc, I'm talking for personal machines) In my book, having unattended-upgrades or windows update run amok on your system is functionally worse than a rootkit.

This. Lost hours from the hours running the updates, lost hours from the occasional faulty upgrade, and every now and again it's fail spectacularly and need a restore from backup to return to productivity. No matter if it's Ubuntu LTS or non-LTS, every six months there's always something radically changed. OpenSUSE Leap has the same problem. I'm looking at Tumbleweed but a new version every week is going to break occasionally. Gentoo build-from-source is going to have weirdness every now and again, if not utter ruin. MacOS updates yearly, and brings horrors with every point zero release. Windows is Windows, and those problems are well known. I don't think there's a way around it with the current offerings.

It's a problem we have to live with for the sake of progress and for security updates. Every machine needs downtime for maintenance on a periodic, often-scheduled basis. It might cost time but avoiding updates is not a good plan.

Aside from dodgy updates that have to run as root to install, if you have passwordless sudo it's more dangerous than any broken package or local-only privilege escalation exploit. I'll wager many have it set up that way, because typing passwords is tiresome.

Re: Maybe you shouldn't install new software for a bit

#310

Literally implemented PR guards today to prevent the team merging any dependencies that didn’t have explicit versions pinned (and that matched the resolution in the lock file). People lamented semver not being trustable but that ship sailed a long time ago, and supply chain attacks are going to get worse before they get better. Our team is pretty minimal when it comes to enforced hooks (everyone has their own workflo…

Wouldn’t you prefer to pin to SHA hashes? Or does your package manager cloud-side ensure immutability of releases?
Post reply on HN