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

231–240 of 497 posts

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

#231

Post by mastermage »

marcus_holmes wrote: post #82
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…

This assumes that there are no new exploits being generated. We're seeing maintainers retreat from maintaining because the amount of AI slop being pushed at them is too much. How many are just going to hand over the maintenance burden to someone else, and how many of those new maintainers are going to be evil? The essential problem is that our entire system of developing civilisation-critical software depends on the…

There is an xkcd about that i think

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

#232

Post by 1a527dd5 »

This applies to much more than just software, in fact it applies to almost everything.

I don't remember where I read it, but it basically boils down to need vs want.

I've used that rule for deciding between a new car or used. A fancy vacuum or basic.

A shiny new gadget.

Bringing new things into the tech stack.

Picking a new tech stack.

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

#233

Post by whilenot-dev »

YZF wrote: post #191
marcus_holmes wrote: post #57

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…

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.

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

#234

Post by HeatrayEnjoyer »

emodendroket wrote: post #226
dataflow wrote: post #219

Earlier quoted context omitted.

> Everyone seems to think they are doing the right thing I like to think people would agree more on the appropriate method if they saw the risk as large enough. If you could convince everyone that a nuclear bomb would get dropped on their heads (or a comparably devastating event) if a vulnerability gets in, I highly doubt a company like #2 would still believe they're doing things optimally, for example.

Really? You think the alternate mode where you're running 5-year-old versions of stuff with tons of known security flaws is better?

>running 5-year-old versions of stuff with tons of known security flaws

No one in this thread proposed that, or anything that could be reasonably assumed to have meant that.

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

#235

Post by coldtea »

emodendroket wrote: post #226
dataflow wrote: post #219

Earlier quoted context omitted.

> Everyone seems to think they are doing the right thing I like to think people would agree more on the appropriate method if they saw the risk as large enough. If you could convince everyone that a nuclear bomb would get dropped on their heads (or a comparably devastating event) if a vulnerability gets in, I highly doubt a company like #2 would still believe they're doing things optimally, for example.

Really? You think the alternate mode where you're running 5-year-old versions of stuff with tons of known security flaws is better?

What part of "We reviewed all relevant CVEs as they came out to make a call on if they apply to us or not and how we mitigate or address them" gave you that impression?

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

#237

Post by metaengies »

Actively destructive opinion article. I could not begin to understand the rationale.

It takes 45 seconds to go check how old the copyfail and dirtyfrag vulnerabilities actually are. Which is longer than it takes to read TFA. Dirtyfrag may be relevant to systems from as far as 2017.

It's not "new" software being affected. And actual old software is in a much worse state because we had a lot more time to find their problems.

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

#238

Post by backwardsponcho »

tjansen wrote: post #197

I wonder whether there is any tool that can prevent npm from downloading any package that has been published in the last month. While I miss out on possible fixes, this would prevent downloading some 3rd level dep that takes over my machine.

NPM seems to have introduced the flag `minimumReleaseAge` for this exact purpose. However even though are many recent references to it[0][1][2] I don't see it anywhere in the NPM documentation.

[0] https://news.ycombinator.com/item?id=47513932

[1] https://github.com/npm/cli/issues/8570

[2] https://socket.dev/blog/npm-introduces-minimumreleaseage-and...

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

#239

Post by smallpipe »

metaengies wrote: post #237

Actively destructive opinion article. I could not begin to understand the rationale. It takes 45 seconds to go check how old the copyfail and dirtyfrag vulnerabilities actually are. Which is longer than it takes to read TFA. Dirtyfrag may be relevant to systems from as far as 2017. It's not "new" software being affected. And actual old software is in a much worse state because we had a lot more time to find their pro…

OP is suggesting that a supply chain attack would be bad now, and to reduce that risk by not installing/updating NPM packages.

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

#240

Post by marcus_holmes »

duskdozer wrote: post #225
marcus_holmes wrote: post #195

Earlier quoted context omitted.

I'm thinking of projects like curl [0] this is a cornerstone of modern software development. If it died, or if got taken over by a malicious entity, every single company on the planet would have an immediate security problem. Yet the experience of that maintainer is bad verging on terrible [1]. We need to do better than this. [0] https://curl.se/docs/governance.html [1] https://lwn.net/Articles/1034966/

>As an example, he put up a slide listing the 47 car brands that use curl in their products; he followed it with a slide listing the brands that contribute to curl. The second slide, needless to say, was empty. >He emphasized that he has released curl under a free license, so there is no legal problem with what these companies are doing. But, he suggested, these companies might want to think a bit more about the futu…

There is a lot of opposition in the FOSS community for restrictive/protective licenses. And to be fair, this comes from a consistent and entirely logical worldview.

There's a bunch of problems with getting companies to pay for this, too - that sense of entitlement (or even contractual obligation), the ability to control the project with cash, etc.

I don't have any answers or solutions. But I don't think we can hand-wave the problem away.

Post reply on HN