Maybe you shouldn't install new software for a bit

psxuaw 348 points 153 comments May 07, 2026
xeiaso.net · View on Hacker News

Discussion Highlights (20 comments)

femiagbabiaka

Yes, and, for non-personal machines or anything connected to the internet: now is a great time to get good at rolling out patches and new releases quickly.

cookiengineer

Fun fact: You still can't build the vllm container with updated dependencies since llmlite got pwned. Either due to regression bugs, or due to impossible transient dependencies in the dependency tree that are not resolvable. There is just too much slopcode down the line, and too many dependencies relying on pinned outdated (and unpublished) dependencies. I switched to llama.cpp because of that. To me it feels more and more that the slopcode world is the opposite philosophy of reproducible builds. It's like the anti methodology of how to work in that regard. Before, everyone was publishing breaking changes in subminor packages because nobody adhered to any API versioning system standards. Now it's every commit that can break things. That is not an improvement.

fkarg

the lottery of either getting a new supply-chain attack or the fixes from Mythos with every single update

cbarnes99

It really pisses me off that responsible disclosure timelines are being ignored.

cperciva

Alternatively, switch to an operating system like FreeBSD which doesn't take a YOLO approach to security. Security fixes don't just get tossed into the FreeBSD kernel without coordination; they go through the FreeBSD security team and we have binary updates (via FreeBSD Update, and via pkgbase for 15.0-RELEASE) published within a couple minutes of the patches hitting the src tree. (Roughly speaking, a few seconds for the "I've pushed the patches" message to go out on slack, 10-30 seconds for patches to be uploaded, and up to a minute for mirrors to sync).

AgentME

There's already an okay solution to supply-chain attacks against dependency managers like npm, PyPI, and Cargo: set them to only install package versions that are more than a few days old. The recent high-profile attacks were all caught and rolled back within a day, so doing this would have let you safely avoid the attacks. It really should be the default behavior. Let self-selected beta testers and security scanner companies try out the newest versions of packages for a day before you try them. Instructions: https://cooldowns.dev/

mistyvales

Fedora upgrades have usually been great, but I jumped the gun on Fedora 44. Sound completely dead with no Pipewire service available. ALSA not responding. Firefox dies immediately if I open a new tab or right click anywhere on the browser itself (inlcuding nightly builds). QEMU refuses to load. Maybe something got completely f'd in the upgrade process.. I never had an issue before having upgraded from Fedora 38 all the way to 43. I am too tired to investigate it all. I know this is unrelated to the article, but related to the title.

jauntywundrkind

I do a bit wonder what happens as standard practice becomes to lag more and more and more. Who is there left that's looking, that'd finding out?

anymouse123456

For the newer players who have gotten into continuous integration and containerized builds, consider checking on your systems to be sure you're not pulling 'latest' across a bunch of packages with every build. We set up our base containers with all the external dependencies already in them and then only update those explicitly when we decide it's time. This means we might be a bit behind the bleeding edge, but we're also taking on a lot less risk with random supply chain vulns getting instant global distribution.

jbrooks84

100% doing this, sadly

0xbadcafebee

"Wait a week to install software" does not work. Just a few months ago a massive exploit hit the web, which was a timed attack which sat for more than a month before executing. If everyone starts waiting a week, their exploits will wait 2 weeks. Cyber criminals do not need to exploit you immediately, they just need to exploit you. (It also doesn't change a large range of vuln classes like typosquatting)

q3k

You don't need a kernel LPE to root a Linux developer machine. Just alias sudo to sudo-but-also-keep-password-and-execute-a-payload in ~/.bashrc and wait up to 24 hours. Maybe also simulate some breakage by intercepting other commands and force the user to run 'sudo systemctl' or something sooner rather than later.

marcus_holmes

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 do without. Well, now we're reaching the "find out" part of the process I guess.

KevinMS

I got rid of half of my VSCode extensions a couple days ago, its too risky.

andai

Can someone help me understand the copyfail thing and how it relates to NPM packages? Edit: I think I understand. copyfail is a kernel bug that lets a malicious npm package get root access on your Linux server, right? So now, while there are unpatched servers, is when it would be the perfect time for attackers to target NPM packages. And the advice isn't just "update your kernel" because we are still finding new related issues?

infrapilot

The scary part is how many teams still have builds implicitly depending on “whatever was latest 5 minutes ago”. Containerization improved reproducibility in some ways, but in practice a lot of CI pipelines still behave like live dependency roulette.

leonidasv

The post is about Linux vulnerabilities, but given the recent supply chain attacks, I'd be especially careful with Homebrew: https://x.com/i/status/2052106143271354859

infrapilot

What’s interesting here is that the exploit chain itself isn’t especially novel anymore — page cache corruption has become a recurring pattern (Dirty Pipe, Copy Fail, Dirty Frag). The worrying part is how quickly public patches are now being reverse-engineered into weaponized exploits. The old “quiet patch before disclosure” model may simply not work anymore in the LLM era.

foo12bar

Don't install anything, use an LLM to write everything from scratch. It may have bugs, but no one will know how to exploit them, especially when closed source. Code is cheap and is becoming cheaper by the day. We need new paradigms.

golem14

This gets me to ask whether I have been hacked . For a few weeks now, both my main mbp and iPhone have been showing unexpected hangs of 1-30 seconds. I can’t find out what’s causing it - not memory pressure, not cpu load. I am worried that the sluggishness appeared about the same time on both devices

Semantic search powered by Rivestack pgvector
8,303 stories · 78,303 chunks indexed