Maybe you shouldn't install new software for a bit
81 points by psxuaw 2 hours ago | 25 comments

cperciva 45 minutes ago
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).
reply
eahm 38 minutes ago
Also funny they never show Debian in those tests/videos.
reply
cperciva 55 seconds ago
Debian is probably the best of all the Linuxes, but still suffers from split-brain: If patches are sent upstream first, Debian can't start digesting them until they're already public.

With FreeBSD there's never any question of "who should this get reported to".

reply
juujian 33 minutes ago
How so?
reply
AgentME 30 minutes ago
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/
reply
cxr 54 seconds ago
[delayed]
reply
edoceo 15 minutes ago
More a case for something like this from Show HN three months ago

https://github.com/artifact-keeper

An artifact manager. Only get what you approve. So you can get fast updates when needed and consistently known stable when you need it. Does need a little config override - easy work.

I had my own janky tooling for something like it. This is a good project.

reply
b112 22 minutes ago
So you get security updates late too? Many vulnerabilities are in the wild for years before being noticed, and patched.

Once noticed, that's where the exploit explosion erupts, excited exploiters everywhere, emboldened... enticed... excessively encouraged, by your delayed updates.

reply
anymouse123456 5 minutes ago
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.

reply
anymouse123456 5 minutes ago
You'll also find your CI build times and flakey failures can be cut down massively by doing this.
reply
mistyvales 16 minutes ago
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.

reply
cevn 7 minutes ago
I had a day 1 crashloop with KWin on the 2nd desktop, but on day 2 some package update fixed it. Honestly it isn't the first time Fedora upgrades have messed something up for me either but I do think it's more stable than the average Ubuntu release, not that I've upgraded ubuntu in like 5 yrs.
reply
dralley 13 minutes ago
I have had none of those issues on Fedora 44, FWIW.
reply
fkarg 2 hours ago
the lottery of either getting a new supply-chain attack or the fixes from Mythos with every single update
reply
cbarnes99 55 minutes ago
It really pisses me off that responsible disclosure timelines are being ignored.
reply
bellowsgulch 46 minutes ago
if you don't already consider responsible disclosure a quaint idea, you may want to grow warm on it

the idea that it exists at all is more or less a gentleman's agreement in the engineering world anyway

reply
roxolotl 53 minutes ago
The dirty frag repo says:

> Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution.

I had to do a double take reading that. It’s written something happened and prevented them from following a schedule but seemingly they chose to release the information. I hope I’m missing something where it was forcibly disclosed elsewhere.

Edit: Moments later I refreshed the homepage and saw the announcement. They do claim to have consulted with maintainers

reply
rafram 23 minutes ago
> Due to external factors, the embargo has been broken, so no patch exists for any distribution.

Very odd wording. I assume there’s an interesting/upsetting story here that will come out soon.

reply
jauntywundrkind 8 minutes ago
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?
reply
femiagbabiaka 2 hours ago
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.
reply
cookiengineer 2 hours ago
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.

reply
2ndorderthought 36 minutes ago
Write only code is such a bad bad idea. No one is reviewing 20k loc PRS with 15 new dependencies in an afternoon. Sorry it's just not happening I don't care how many years you have been a software engineer. Yet that's the new thing and how we all are supposed to work or else we are all Luddites.
reply
throwaway613746 39 minutes ago
[dead]
reply
cyanydeez 2 hours ago
but we were just last month asking where all that great productivity was coming with the AI wave, and now everyones got some AI bit and bob that was vibe coded with the idea that the cloude providers have an endless stream of capacity for the endless slop trough we're all dying to dine at.
reply
_--__--__ 2 hours ago
? This is related to a vulnerability that was introduced to the Linux kernel in 2017.
reply
ChrisClark 48 minutes ago
What?
reply