[dead]
Malicious versions of Nx and some supporting plugins were published
441–450 of 460 posts
Re: Malicious versions of Nx and some supporting plugins were published
#442Re: Malicious versions of Nx and some supporting plugins were published
#443Earlier quoted context omitted.
How? bubblewrap isn't something someone has randomly uploaded to npm, it has well known maintainers and a well organised release process (including package signing). Which is easier to do: upload a package to npm and get people to use it, or spend 2+ years trying to become a maintainer of bubblewrap or one of its dependencies to compromise it.
Sure, but there's plenty of packages with well-known maintainers who get compromised...
The fact that something can happen is separate from how likely that thing is to happen, and that’s what matters here.
The comments here that point to this theoretical possibility seem to be missing the point, which is that using something like bubblewrap is an improvement over running arbitrary projects un-sandboxed, and the likelihood of such an attack is far less than the likelihood of any one of hundreds of rapidly evolving, lesser known, lesser scrutinized projects getting compromised.
Re: Malicious versions of Nx and some supporting plugins were published
#444People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…
In pure functional programming like elm and Haskell, it is extremely easy to audit dependencies because any side effect must be explicitly listed, so you just search for those. That makes the risk way lower for dependencies, which is an underrated strength.
Re: Malicious versions of Nx and some supporting plugins were published
#445Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…
Whenever I read this well-meaning advice I have to ask: Do you actually read hundreds of thousands of lines of code (or more) that NPM installed? Because the workflow for 99.99% of developers is something resembling: 1. git clone 2. npm install (which pulls in a malicious dependency but disabling post-install scripts saved you for now!) 3. npm run (executing your malicious dependency, you're now infected) The only wa…
Yeah I guess it probably helps you specifically, because most malware is going to do the lazy thing and use install scripts. But it doesn't help everyone in general because if e.g. NPM disabled those scripts entirely (or made them opt-in) then the malware authors would just put their malware into the `npm run` as you say.
Re: Malicious versions of Nx and some supporting plugins were published
#446Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…
I also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers: #!/usr/bin/bash bin=$(basename "$0") exec bwrap \ --bind ~/.cache/nodejs ~/.cache \ --bind ~/code ~/code \ --dev /dev \ --die-with-p…
[deleted]
Re: Malicious versions of Nx and some supporting plugins were published
#447Earlier quoted context omitted.
I do too, but I found it non-trivial to actually secure the podman container. I described my approach here [1]. I'm very interested to hear your approach. Any specific podman flags or do you use another tool like toolbx/distrobox? [1]: https://evertheylen.eu/p/probox-intro/
Very interesting. I learned some new things. I didn't know about `--userns` or the flexible "bind everything" network approach! Here's my script: https://codeberg.org/chrisdavies/dotfiles/src/branch/main/sr... What I do is look for a `.podman` folder, and if it exists, I use the `env` file there to explicitly bind certain ports. That does mean I have to rebuild the container if I need to add a port, so I usually bind…
Yeah props to the `pasta` tool, it solves a specific problem really well.
Nice script! I considered a similar approach that's based on "magic" files in the filesystem before, but it was difficult to get the security right. In your case I believe a malicious script can just overwrite .podman/env and it will be sourced by the host the next time you start the container.
I'm happy to discuss this more, feel free to reach out at evertheylen@gmail.com. I'm particularly interested in trying automated ways to try to break out of a container (like https://github.com/brompwnie/botb), this would benefit any containerization project.
Re: Malicious versions of Nx and some supporting plugins were published
#448Earlier quoted context omitted.
It means that someone just has to compromise bubblewrap instead of the other vectors.
Am I getting bubblewrap somewhere other than my distro? What makes it different from any other executable that comes from there?
Nothing. Does your threat model assume 100% trust in your distro? I understand saying you trust it a lot more than the garbage on npm. But if your trust is anything less than 100%, you are balancing risk and benefit.
Re: Malicious versions of Nx and some supporting plugins were published
#449Earlier quoted context omitted.
But that would lock me in to say whatever $debian provides. And some dependencies only exist as source because they are not packaged for $distribution. Of course, if possible, just saying "hey, I need these dependencies from the system" is nicer, but also not error-free. If a system suddenly uses an older or newer version of a dependency, you might also run into trouble. In either case, you run into either an a) trus…
> If a system suddenly uses an older or newer version of a dependency, you might also run into trouble. You won't. The user may. On his system.
Aware of that. So how is that different from any other Debian package? If you rely on a certain set of packages, you are always at the end at fault. You either trust a certain base or you vet it.
Re: Malicious versions of Nx and some supporting plugins were published
#450The same thing that happend to grafana?
https://grafana.com/blog/2025/05/15/grafana-security-update-...