821–830 of 1001 posts
Earlier quoted context omitted.
Github is a centralized repository where the overwhelming majority of Go libraries are hosted.
So GitHub is every single programming language's centralized package repository? Then what's the difference between git and npm, cargo, pypi, mvn et al?
In practice, little difference between Go's use of Github and Python's use of PyPI. Someone at Microsoft with root access could compromise everyone.
This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…
As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
There are no real solutions to the problem, except for reducing exposure somewhat by limiting yourself to a mostly frozen subset of packages that are hopefully vetted more stringently by more people.
Earlier quoted context omitted.
The argument wasn’t to import five dependencies, one for each of the functions, but to write the five functions yourself . Heck, you don’t even need to literally write them, check the Lodash source and copy them to your code.
You have obviously never checked the Lodash source.
Earlier quoted context omitted.
You have obviously never checked the Lodash source.
The point here isn’t a specific library. It’s not even one specific language or runtime. No one is talking about literally five functions. Let’s not be pedantic and lose sight of the major point.
Earlier quoted context omitted.
Right. Allowing 500 strangers to push code to our CI infra, or developer laptops, with approximately zero review, sounds similarly ill advised. That JLR got their factories hacked, rather than customer cars , is less bad for sure. But it's still pretty bad. Also, before arguing that code generators should get a pass as they don't “end up in the final product”, you really should read “Reflections on trusting trust” by…
> Right. Allowing 500 strangers to push code to our CI infra That's bullshit, pure and simple. If you pull in a deeply nested dependency like icu_normalizer it has 30 dependencies, OMGHAXOZRS. I'm doing this, so I don't have to spend a day going through the library. Except of the 30 depedencies crates, there are 10 from ICUX repository, and then you have almost standard dependencies like proc-macro/syn/quote crates f…
Isn't it actually the case that you started with 3 strangers, but 27 of them were relatively easy (still took some time) to figure out as safe?
Earlier quoted context omitted.
Thank you. It's frustrating when people uncommon acronyms without explaining them.
AI is helpful for this, but I also built https://www.hackterms.com eight years ago for this exact reason.
Earlier quoted context omitted.
What other language ecosystems have had this happen systematically? This isn't even the first time this month!
NPM is the most popular, so it happens the most frequently. All of the other ecosystems are just as susceptible. Unix had a big scare last year because of XZ Utils. https://en.wikipedia.org/wiki/XZ_Utils_backdoor
As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…
I was shocked when I found out that at some of the most profitable shops, most of their code is just a bunch of different third-party libraries badly cobbled together, with only a superficial understanding of how those libraries work.
Earlier quoted context omitted.
> --bind "${PWD}" "${PWD}" Pardon my ignorance, but couldn't a malicious actor just redefine $PWD before calling a npm script?
The above script wraps npm. PWD gets evaluated before npm is called (so PWD is expanded in the "outside" environment). Of course, if your malicious actor has access to your environment already, they can redefine PWD, but that's assuming you're already compromised. This bwrap script is to avoid that malicious actor running malicious install scripts in the first place. However, I don't think it protects you against stu…