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

GitLab discovers widespread NPM supply chain attack

about.gitlab.com

Post reply on HN
Print view View original

231–240 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#231

Post by hombre_fatal »

naikrovek wrote: post #170
douglascamata wrote: post #116

Earlier quoted context omitted.

Apparently, The Github CLI only stores its oauth token in the HOME directory if you don't have a keyring. They also say it may not work on headless systems. See https://github.com/cli/cli/discussions/7109 . For example, in my macOS machines the token is safely stored in the OS keyring (yes, I double checked the file where otherwise it would've been stored as plain text).

Yes. KeePassXC is all you need on Linux to have a compatible secret store.

I use it as my secret store provider but it has its quirks.

It would be better if you could have multiple providers attached (gnome-keyring and keepassxc) and then decide which app uses which provider.

Because only some secrets you want to share across devices, like wifi passwords, and the rest you don’t, like the key chromium uses to encrypt local cookies or the gh cli token.

Re: GitLab discovers widespread NPM supply chain attack

#232

Post by brendyn »

naikrovek wrote: post #169
didntcheck wrote: post #85

Earlier quoted context omitted.

That's true, but the same may already be true of your browser's cookie file. I believe Chrome on MacOS and Windows (unsure about Linux) now does use OS features to prevent it being read from other executables, but Firefox doesn't (yet) But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than endlessly updating a patchy blacklist

Plan9 had per-process namespaces in 1995. One could easily allow or restrict visibility of almost anything to any program. There were/are some definite usability concerns with how it is done today (the OS was not designed to be friendly, but to try new things) and those could easily be solved. The core of this existed in the Plan9 kernel and the Plan9 kernel is small enough to be understood by one person. I’m kinda a…

I think this normalises running untrustworthy, abusive proprietary software, because they can at least be somewhat contained. The only reason I have apps like Facebook on my android phone is that I have sufficient trust in GrapheneOSs permissions. Then, apps like syncthing become crippled as filesystem virtualisation and restrictions prevent access and modification of files regardless of my consent.

Not disagreeing with the need for isolation though, I just think it should be designed carefully in a zero-sacrifice way (of use control/pragmatic software freedom)

Re: GitLab discovers widespread NPM supply chain attack

#233

Post by naikrovek »

nyrikki wrote: post #217
naikrovek wrote: post #214

Earlier quoted context omitted.

You are missing my point, maybe. Plan9 had this by default in 1995, no third party tools required. You launch a program, it gets its own namespace, by default it is a child namespace of whatever namespace launched the program. I should not have to read anything to have this. Operating systems should provide it by default. That is my point. We have settled for shitty operating systems because it’s easier (at first gla…

You seem to have a misunderstanding of what namespaces accomplished on plan9, or that it was extending Unix concepts and assembling them in another way. As someone who actually ran plan9 over 30 years ago I ensure that if you go back and look at it, the namespaces were intended to abstract away the hardware limitations of the time, to build distributed execution contexts of a large assembly of limited resources. And…

Kubernetes is an operating system on top of an operating system. Its complexity is insane.

The base OS should be providing a lot/all of these features by default.

Plan9 is as you describe out of the box, but what I want is what plan9 might be if it were designed today and could be with a little work. Isolation would not be terribly difficult to add to it. The default namespace a process gets by default could limit it to its own configuration directory, its own data directory, and standard in and out by default. And imagine every instance of that application getting its own distinct copy of that namespace and none of them can talk to each other or scan any disk. They only do work sent to them via stdin, as dictated in the srv configuration for that software.

Everything doesn’t HAVE to be a file, but that is a very elegant abstraction when it all works.

> call the ip() command and run your app in an isolated namespace with a single command if you wanted to.

I should not have to opt in to that. Processes should be isolated by default. Their view of the computer should be heavily restricted; look at all these goofy NPM packages running malware, capturing credentials stored on disk. Why can an NPM package see any of that stuff by default? Why can it see anything else on disk at all? Why is everything wide fucking open all the time?

Why am I the goofy one for wanting isolation?

Re: GitLab discovers widespread NPM supply chain attack

#234

Post by naikrovek »

nyrikki wrote: post #184
naikrovek wrote: post #168

Earlier quoted context omitted.

Here I go again: Plan9 had per-process namespaces in 1995. The namespace for any process could be manipulated to see (or not see) any parts of the machine that you wanted or needed. I really wish people had paid more attention to that operating system.

The tooling for that exists today in Linux, and it is fairly easy to use with podman etc. K8s choices clouds that a little, but for vscode completions as an example, I have a pod, that systemd launches on request that starts it. I have nginx receive the socket from systemd, and it communicates to llama.cpp through a socket on a shared volume. As nginx inherits the socket from systemd it does have internet access eith…

> If it is something people would find useful please leave a comment.

I would love to know.

Re: GitLab discovers widespread NPM supply chain attack

#235

Post by gizmo686 »

sigmoid10 wrote: post #141
qubex wrote: post #102

About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “bre…

This is why you want containerisation or, even better, full virtualisation. Running programs built on node, python or any other ecosystem that makes installing tons of dependencies easy (and thus frustratingly common) on your main system where you keep any unrelated data is a surefire way to get compromised by the supply chain eventually. I don't even have the interpreters for python and js on my base system anymore…

That can only go so far. Assuming there is no container/VM escape, most software is built to get used. You can protect yourself from malicious dependencies in the build step. But at some point, you are going to do a production build, that needs to run on a production system, with access to production data. If you do not trust your supply chain; you need to fix that.

If you excuse me, I have a list of 1000 artifacts I need to audit before importing into our dependency store.

Re: GitLab discovers widespread NPM supply chain attack

#236

Post by naikrovek »

ElectricalUnion wrote: post #219
naikrovek wrote: post #214

Earlier quoted context omitted.

You are missing my point, maybe. Plan9 had this by default in 1995, no third party tools required. You launch a program, it gets its own namespace, by default it is a child namespace of whatever namespace launched the program. I should not have to read anything to have this. Operating systems should provide it by default. That is my point. We have settled for shitty operating systems because it’s easier (at first gla…

The fact that tools like docker, podman and bubblewrap exist and work points out that the OS supports it, but using the OS APIs directly sucks. Otherwise the only "safe" implementations of such features would need a full software VM. If using software securely was really a priority, everyone would be rustifing everything, and running everything in separated physical machines with restrictive AppArmor, SELinux, TOMOYO…

> The fact that tools like docker, podman and bubblewrap exist and work points out that the OS supports it

Only via virtualization in the case of MacOS. Somehow, even windows has native container support these days.

A much more secure system can be made I assure you. Availability is important, but an NPM package being able to scan every attached disk in its post-installation script and capture any clear text credentials it finds is crossing the line. This isn’t going to stop with NPM, either.

One can have availability and sensible isolation by default. Why we haven’t chosen to do this is beyond me. How many people need to get ransomwared because the OS lets some crappy piece of junk encrypt files it should not even be able to see without prompting the user?

Re: GitLab discovers widespread NPM supply chain attack

#237

Post by jazzypants »

bakkoting wrote: post #208
philipwhiuk wrote: post #178

Earlier quoted context omitted.

The lesson surely though is 'don't use web-tech, aimed at solving browser incompatibility issues for local scripting'. When you're running NPM tooling you're running libraries primarily built for those problems, hence the torrent of otherwise unnecessary complexity of polyfills, that happen to be running on a JS engine that doesn't get a browser attached to it.

Very few packages published on npm include polyfills, especially packages you'd use when doing local scripting.

I'm sorry, but this is just incorrect. Have you ever heard of ljharb[0]? The NPM ecosystem is rife with polyfills[1]. I don't know how you can make a distinction on which libraries would be used for "local scripting" as I don't think many library authors make that distinction.

[0] - TC39 member who is self-described as "obsessed with backwards compatibility": https://github.com/ljharb

[1] - Here's one of many articles describing the situation: https://marvinh.dev/blog/speeding-up-javascript-ecosystem-pa...

Re: GitLab discovers widespread NPM supply chain attack

#238

Post by tucnak »

2OEH8eoCRo0 wrote: post #144
qubex wrote: post #102

About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “bre…

It's funny because techies love to tell people that common sense is the best antivirus, don't click suspicious links, etc. only to download and execute a laundry list of unvetted dependencies with a keystroke.

But.. but... we're all friends here!

Re: GitLab discovers widespread NPM supply chain attack

#240

Post by nektro »

sigmoid10 wrote: post #141
qubex wrote: post #102

About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “bre…

This is why you want containerisation or, even better, full virtualisation. Running programs built on node, python or any other ecosystem that makes installing tons of dependencies easy (and thus frustratingly common) on your main system where you keep any unrelated data is a surefire way to get compromised by the supply chain eventually. I don't even have the interpreters for python and js on my base system anymore…

nixos solves this without vms
Post reply on HN