Earlier quoted context omitted.
You are allowed to read Cargo.toml.
Cargo.toml does not contain the source code of dependencies nor transient dependencies.
Welp, `cargo tree`, 100 nights and 100 coffees then it is
Malicious versions of Nx and some supporting plugins were published
221–230 of 460 posts
Re: Malicious versions of Nx and some supporting plugins were published
#222Earlier quoted context omitted.
The problem is less the size of a single dependency but the transitivity of adding dependencies. It used to be, library developers sought to not depend on other libraries if they could avoid it, because it meant their users had to make their build systems more complicated. It was unusual for a complete project to have a dependency graph more than two levels deep. Package managers let you easily build these gigantic d…
The size itself isn’t a problem, it’s just a rough indicator of the benefit you get. If it’s only replacing a hundred lines of code, is it really worth bringing in a dependency, and as you point out potentially many transitive dependencies, instead of writing your own? People understood this with left-pad but largely seemed unwilling to extrapolate it to somewhat larger libraries.
You are probably bringing in 10-1000 lines of code for every 1 line you did not have to write (I am sure some good estimate could be calculated?), since all the libraries support cases you do not need. This also tends to result in having to use APIs that are far more complex than they have to be. In addition to security risks.
Re: Malicious versions of Nx and some supporting plugins were published
#223Earlier quoted context omitted.
> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…
Rust makes me especially nervous due to the possibility of compile-time code execution. So a cargo build invocation is all it could take to own you. In Go there is no such possibility by design.
Build script isn't a big issue for Rust because there is a simple mitigation that's possible. Do the build in a secure sandbox. Only execution and network access must be allowed - preferably as separate steps. Network access can be restricted to only downloading dependencies. Everything else, including access to the main filesystem should be denied.
Runtime malicious code is a different matter. Rust has a security workgroup and their tools to address this. But it still worries me.
Re: Malicious versions of Nx and some supporting plugins were published
#224Earlier quoted context omitted.
Part of the value proposition for bringing in outside libraries was: when they improve it, you get that automatically. Now the threat is: when they “improve” it, you get that automatically. left-pad should have been a major wake up call. Instead, the lesson people took away from it seems to have mostly been, “haha, look at those idiots pulling in an entire dependency for ten lines of code. I, on the other hand, am in…
So, what's the acceptable LOC count threshold for using a library? Maybe scolding and mocking people isn't a very effective security posture after all.
Time for everybody's favorite engineering answer: it depends! You have to weigh the cost/benefit tradeoff. But you have to do it in full awareness of the costs, including potential costs from packages being taken down, broken, or subverted. In any case, for an external dependency, 100 lines is way too low of a benefit.
I'm not trying to be effective, I'm just lamenting. Maybe being sarcastic isn't a very effective way to get people to be effective?
Re: Malicious versions of Nx and some supporting plugins were published
#225May be give vet a try. It detected most of the malicious packages within few hours of publishing to npm.
GitHub: https://github.com/safedep/vet
Re: Malicious versions of Nx and some supporting plugins were published
#226How can we stop having post-install scripts with such access? Can I turn off those post install scripts globally? Are there alternatives to npm that do a better job here?
You can use pnpm, which forces you to approve the install scripts you want to run.
Do you approve on every update of the package? Do they offer a way to quickly review what’s going to run and what has changed since the last approval? Otherwise it’s just like another checkbox of “I confirm I read the terms and conditions”
Re: Malicious versions of Nx and some supporting plugins were published
#227It would be surprising if claude code would actually run that prompt, so I tried run it: > I can't help with this request as it appears to be designed to search for and inventory sensitive files like cryptocurrency wallets, private keys, and other secrets. This type of comprehensive file enumeration could be used maliciously to locate and potentially exfiltrate sensitive data. If you need help with legitimate securit…
I have evidence of at least 250 successes for the prompt. Claude definitely appears to have a higher rejection rate. Q also rejects fairly consistently (based on Claude, so that makes sense).
Context: I've been responding to this all day, and wrote https://www.wiz.io/blog/s1ngularity-supply-chain-attack
Re: Malicious versions of Nx and some supporting plugins were published
#228Earlier quoted context omitted.
Fully agree. That is why I vendor all my dependencies. On the common lisp side a new tool emerged a while ago for that[1]. On top of that, I try to keep the dependencies to an absolute minimum. In my current project it's 15 dependencies, including the sub-dependencies. [1]: https://github.com/fosskers/vend
Vendoring is nice. Using the system version is nicer. If you can’t run on $current_debian, that’s very much a you problem. If postgres and nginx can do it, you can too.
That is an impossible task in practice for most developers.
Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a developer to depend on every possible variation of such packages, across many distros, is a tall order. Postgres and Nginx might be able to do it, but those are established projects with large teams behind them and plenty of leverage. They might even be able to influence distro maintainers to their will, since no distro will want to miss out on carrying such popular packages.
So vendoring is in practice the only sane choice for smaller teams and projects.
Besides, distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain. It exists in this weird unspecified state that can technically be useful for end users, but is completely useless for developers. Are they supposed to develop on a specific distro for some reason? Should it carry sources or only binaries? Is the dependency resolution the same for all languages? Should language tooling support them? It's an entirely ridiculous practice that should be abandoned altogether.
Yes, it's also silly that every language has to reinvent the wheel for managing dependencies, and that it can introduce novel supply chain attack vectors, but the alternative is a far more ludicrous proposition.
Re: Malicious versions of Nx and some supporting plugins were published
#229People 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…
> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…
This isn't as new as you make it out, ant + ivy / maven / gradle had already started this in the 00s. Definitely turned into a mess, but I think the java/cross platform nature pushed this style of development along pretty heavily.
Before this wasn't CPAN already big?
Re: Malicious versions of Nx and some supporting plugins were published
#230Earlier quoted context omitted.
Fully agree. So many people are so drunk on the kool aid, I often wonder if I’m the weirdo for not wanting dozens of third party libraries just to build a simple HTTP client for a simple internal REST api. (No I don’t want tokio, Unicode, multipart forms, SSL, web sockets, …). At least Rust has “features”. With pip and such, avoiding the kitchen sink is not an option. I also find anything not extensively used has bug…
For this specific case an llm may be a good option. You know what you want and could do it yourself but who wants to type it all out? An llm could generate an http client from the socket level on up and it would be straightforward to verify. "Create an http client in $language with basic support for GET and POST requests and outputs the response to STDOUT without any third party libraries. after processing command li…
Sure, after all, when has vibe coding ever resulted in security issues?