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

211–220 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#211

Post by mxey »

febusravenga wrote: post #75
wonderfuly wrote: post #67

I'm a victim of this. In addition to concerns about npm, I'm now hesitant to use the GitHub CLI, which stores a highly privileged OAuth token in plain text in the HOME directory. After the attacker accesses it, they can do almost anything on behalf of me, for example, they turned many of my private repos to public.

this, this, this All our tokens should be in is protected keychain and there are no proper cross-platform solutions for this. All gclouds, was aww sdks, gh and other tools just store them in dotfile. And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

> And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

https://developer.apple.com/documentation/security/keychain-...

And similar services exist on Linux desktops. There are libraries that will automatically pick the right backend.

Re: GitLab discovers widespread NPM supply chain attack

#212

Post by mxey »

masfuerte wrote: post #154
1718627440 wrote: post #137

Earlier quoted context omitted.

> This does mean entering your keyring password a lot. Not when you put that keyrings password into the user keyring. I think it is also cached by default.

Then what stops the malware accessing the keyring?

On disk, it’s encrypted. The running service, at least on macOS, only hands the item out to specific apps, based on their code signing identity.

Re: GitLab discovers widespread NPM supply chain attack

#213

Post by metachris »

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…

Absolutely, good old VMs can really provide the needed isolation while still having good UX. I just published a post on setting up dev VMs with Lima: https://www.metachris.dev/2025/11/sandbox-your-ai-dev-tools-...

Re: GitLab discovers widespread NPM supply chain attack

#214

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…

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 glance) to add stuff on top than it is to have an OS provide these things. It turns out this isn’t easier, and we’re just piling shit on top of shit because it seems like the easiest path forward.

Look how many lines of code are in Plan9 then look at how many lines of code are in Docker or Kubernetes. It is probably easier to write operating systems with features you desire than it is to write an application-level operating system like Kubernetes which provide those features on top of the operating system. And that is likely due to application-scope operating systems like Kubernetes needing to comply with the existing reality of the operating system they are running on, while an actual operating system which runs on hardware gets to define the reality that it provides to applications which run atop it.

Re: GitLab discovers widespread NPM supply chain attack

#216

Post by AmbroseBierce »

nottorp wrote: post #101
AmbroseBierce wrote: post #97

Earlier quoted context omitted.

Pretty sure Microsoft is exponentially bigger than 99% of the library authors out there, and add to that the giant communication channel that GitHub gives it over developers, so the analogy breaks pretty fast.

Or it's worse, because there's a good bunch of devs that don't trust MS by default?

Even the most hardcore GNU supporters don't think Microsoft would add a supply chain attack to such initiative, or that their software security is worse than the average NPM (popular) package maintainer.

Re: GitLab discovers widespread NPM supply chain attack

#217

Post by nyrikki »

naikrovek wrote: post #214
nyrikki wrote: post #184

Earlier quoted context omitted.

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…

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 if you have an issue with Unix sockets you would have hated it as it didn’t even have stalls and everything was about files.

Today we have a different problem, where machines are so large that we have to abstract them into smaller chunks.

Plan9 was exactly the opposite, when your local system CPU is limited you would run the cpu command and use another host, and guess what, it handed your file descriptors to that other machine.

The goals of plan9 are dramatically different than isolation.

But the OSes you seem to hate so much implemented many of the plan9 ideas, like /proc, union file systems, message passing etc.

Also note I am not talking about k8s in the above, I am talking about containers and namespaces.

K8s is an orchestrater, the kernel functionality may be abstracted by it, but K8s is just a user of those plan9 inspired ideas.

Netns, pidns, etc… could be used directly, and you can call unshare(2)[0] directly, or use a cri like crun or use podman.

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

You don’t need an api or K8s at all.

[0] https://man7.org/linux/man-pages/man2/unshare.2.html

Re: GitLab discovers widespread NPM supply chain attack

#219

Post by ElectricalUnion »

naikrovek wrote: post #214
nyrikki wrote: post #184

Earlier quoted context omitted.

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…

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 and Landlock profiles, with mTLS everywhere.

It turns out that in Security, "availability" is a very important requirement, and "can't run your insecure-by-design system" is a failing grade.

Re: GitLab discovers widespread NPM supply chain attack

#220

Post by ElectricalUnion »

Hendrikto wrote: post #145
akshitgaur2005 wrote: post #131

Earlier quoted context omitted.

Maybe I am missing something but how and why would a display protocol have anything to do with file access model??

In Wayland you have these xdg-portals that broker access to the filesystem, microphone, webcam, etc. I am not knowledgeable about the security model though.

Portals are used to integrate applications to the host if they're being run inside a sandboxed environment.

They are hooks that latch on the common GUI application library calls for things such as "open file dialogs" such that exeptions to the sandbox are implicitly added as-you-go.

They cannot prevent for example direct filesystem access if the application has permission to open() stuff, like if they're not running in a sandbox, or if said sandbox have a "can see and modify entire filesystem" exception (very common on your average flatpak app, btw).

Post reply on HN