Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

311–320 of 497 posts

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

#312
post #300
post #257

Earlier quoted context omitted.

The problem is that they get away too easily with bugs in their products they ship to customers. If this would come with some penalties, there would be some incentive to invest in security and this would probably often flow back to upstream projects.

Like a money-back guarantee? Like you get when you buy e.g. MS products? /s

I am not talking about the open-source projects, but the downstream products such as cars that integrate curl.

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

#313
post #161

Earlier quoted context omitted.

I think it will be an arms race in the future as well. Easier to fix known vulnerabilities automatically, but also easier to find new ones and the occasionally AI fuckup instead of the occasionally human fuckup.

Yeah. Right now it kinda feels to me like "Open Source" is the Russian army, assuming their sheer numbers and their huge quantity of equipment much off which is decades old. Meanwhile attackers and bug hunters are like the Ukrainians, using new, inexpensive, and surprisingly powerful tools that none of the Open Source community has ever seen in the past, and for which it has very little defence capability. The attack…

Well this argument was certainly inventive. What a weird impression to have about these things.

Who exactly is the innocent little Ukraine supposed to be that the big bad open source is supposed to be attacking to, what? take their land and make the OSS leader look powerful and successful at acheiving goals to distract from their fundamental awfulness? And who are the North Korean canon fodder purchased by OSS while we're at it?

Yeah it's just like that, practically the same situation. The authors of gnu cp and ls can't wait to get, idk, something apparently, out of the war they started when they attacked, idk, someone apparently.

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

#314

So what do we do? Pin our dependencies (to hashes when possible), and only update when there are CVEs? But problem is this could lead to abuse of the CVE system to try to force rapid adoption of attacked packages. What prevents this?

Nothing :D

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

#315

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…

lim (num_packages_in_system -> inf) p(successful_supply_chain_attack) = 1

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

#317

Earlier quoted context omitted.

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.

doesn't `npm ci` prevent that? it fails if something doesn't match the lockfile, and wipes node_modules before running

this is on some ancient node 16 build i was trying to clean up ci for, so not very recent npm

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

#318

So what do we do? Pin our dependencies (to hashes when possible), and only update when there are CVEs? But problem is this could lead to abuse of the CVE system to try to force rapid adoption of attacked packages. What prevents this?

Run everything as sudo so they cant escalate any further ;)

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

#319
post #179

Earlier quoted context omitted.

I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer. One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable pack…

>C/C++ are doing fine without package managers. They're not either, every one of these projects contains a gigantic vendor/ folder full of unmaintained libraries, modified so much that keeping up with the latest changes is impossible so they're stuck with whatever version they copied back in 2009.

You make that sound worse than it is. On the overall topic, you have 0 supply chain risk, and the whole thing is local. Also, your code from 2009 is still valid. That would be a foreign concept in some languages like Python.

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

#320

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…

Web pages handled by browsers. Linux desktop running code without sandbox is reckless, relied on verification by distro maintainers, does not work the moment users run proprietary software.

Programming language packages issue only because we don't have zero trust for modules — no restrictions to open socket or file system. Issue is not count, pure function leftPad can't hurt you.

Post reply on HN