Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

Post reply on HN
Print view View original

241–250 of 497 posts

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

#241

Post by Gigachad »

andai wrote: post #60

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 rela…

The patches for the latest vulnerabilities aren’t even out yet. So it would be a real bad time for a new supply chain attack since it would get root on pretty much every system.

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

#242

Post by spockz »

akoboldfrying wrote: post #124
cratermoon wrote: post #118

Earlier quoted context omitted.

Typically when hand-rolling code you implement only what you require for your use-case, while a library will be more general purpose. As a consequence of doing more, have more code and more bugs. Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. For supply chain security and bug count, I'll take a focused custom implementation of specific fea…

Yes, a lot hinges on how little you can get away with implementing for your use case. If you have an XML config file with 3 settings in it, you probably won't need to implement handling of external entities the way a full XML parsing library would, which will close off an entire class of attendant vulnerabilities. > Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certa…

This argument goes even further. If you have only 3 settings, why does it need to be an xml file?

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

#243

Post by dijit »

cperciva wrote: post #11

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…

FreeBSD is quite lax when it comes to security- especially defaults and configs.

The preference is for usability over security.

Famously: https://vez.mrsk.me/freebsd-defaults

I appreciate your work on the project, but I can’t in good conscience suggest people switch while are such bad defaults.

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

#244

Post by JoshTriplett »

cperciva wrote: post #186
JoshTriplett wrote: post #47

Earlier quoted context omitted.

> Debian can't start digesting them until they're already public Not sure what you mean by this. Debian is able to handle coordinated disclosures (when they're actually coordinated), and get embargoed security updates out rapidly without breaking the embargo. Is there some other aspect of this that you're referencing?

The key words there are "when they're actually coordinated". Debian doesn't own the Linux kernel, and the kernel developers don't bother with coordinated disclosure, so the happy path of coordinated disclosure only happens when reporters make the non-obvious choice of reporting vulnerabilities to people other than the maintainers .

Fair enough; yeah, at the point where the embargo failed, it was important that patches get to distros as fast as possible in order to ship the fixes.

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

#245

Post by spockz »

larodi wrote: post #174
teiferer wrote: post #170

Earlier quoted context omitted.

That is already how it works. The loner hacker in moms basement working for free on his super critical OSS package is largely a myth. The vast majority of OSS code is contributed by companies paying their employees to work on it.

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.

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

#246

Post by akoboldfrying »

bigiain wrote: post #192
akoboldfrying wrote: post #153

Earlier quoted context omitted.

Do you have a specific library in mind? I think it would have to be an ancient, unmaintained C library. But I think most OSS code isn't like this -- even C code born long ago, if it's still in wide use, has been hardened by now. Examples: Linux kernel, GNU userland, PostgreSQL, Python.

> 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)

Sure, I didn't mean to say that these examples are guaranteed 100% safe -- just that I trust them to be enormously more safe than software that accomplishes the same task that was hand-written by either a human or an an LLM last week.

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

#248

Post by hennell »

whilenot-dev wrote: post #233
YZF wrote: post #191

Earlier quoted context omitted.

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…

You forgot case #4: Worked at a startup where the frontend team thought it was a good idea to use lock files during development, but to do a "fresh" install of all dependecies during the deployment step. And yes, they still thought they were doing the right thing.

To be fair npm makes (made?) it weirdly hard to use lock files so a lot of people did that by mistake. And when you do use lock, it reinstalls every time so a retagged package can just silently update.

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

#249

Post by mastermage »

I think what we have to start accepting even security experts is that our world is incredibly fragile. I think people realy understimate this. And I do not mean just the IT world but the entire world is built on many incredibly fragile balances. Security Exploits will always exist. Not just in software but in real life. Heck someone managed to Sneak into a Security Conference. And that guy was a random youtuber. Granted that was not like a high security thing. But thats just an example I had of the top of my head. Basically it is realy easy to circumvent security in most cases.

What I want to say with that is fundamentally our world works because atleast most people do not abuse shit. That is fundamentally how human society has always worked, and will likely continue to do so.

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

#250

Post by repelsteeltje »

allthetime wrote: post #98
tclancy wrote: post #65

Earlier quoted context omitted.

So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property t…

New software is being generated faster than it can be adequately tested. We are in the same place we’ve always been; except everything is moving much too fast.

This is exactly the feeling I have. First: excessive growth of dependencies fueled by free components.

* with internet access to FOSS via sourceforge and github we got an abundance of building blocks

* with central repositories like CPAN, npm, pip, cargo and docker those building blocks became trivially easy to use

Then LLMs and agents added velocity to building apps and producing yet more components, feeding back into the dependency chain. Worse: new code with unattributed reuse of questionable patterns found in unknowable versions of existing libraries. That is, implicit dependencies on fragments multitude of packages.

This may all end well ultimately, but we're definitely in for a bumpy ride.

Post reply on HN