371–380 of 494 posts
Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…
theoretical question, do cooldowns still work if everyone has them?
Earlier quoted context omitted.
I don't agree that nobody is adopting them. Can you please elaborate? - Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus. They have ways to bypass it for urgent CVEs - pnpm just adopted 24 hours cooldown as default, based on community feedback.
what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly e…
I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
1. Packj (https://github.com/ossillate-inc/packj) detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting).
Earlier quoted context omitted.
> Should we instead of these cooldowns just run builds in isolated contexts? I'd suggest both. Cooldown for 1-2 days is very cheap and you likely won't even notice it, so it's quite harmless and from what I've seen even just 24 hours is enough to let security companies pick up malware. But yeah, isolation is a must-have.
At this point, is there an obligation of package managers, or at least npm to arrange the sandboxing themselves? Or as us or companies to wrap the build tools to provide the wrapping for them.
Earlier quoted context omitted.
Python does too I believe. Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly. The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it ob…
A lot of packages are pulled in to call minimal bits of the actual library. I obviously don't have any statistics on this but my instinct would say that for the average application only 5% of an average package is actually used. So not running package installation scripts is a huge, massive problem.
mkdir demo && cd demo
npm install --save koa@3.2.0
echo 'console.log("--- pwned by a transitive dependency ---")' >> node_modules/tsscmp/lib/index.js
node -e "import 'koa'"
Earlier quoted context omitted.
A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening
From that repo: > Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid. My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing acr…
That's where the lockfile comes in, it pins the dependencies of the dependencies.
Earlier quoted context omitted.
> Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly use…
Changing oil requires > a place where you have sufficient access to the vehicle to drain it Probably the only valid argument for people who park on the street. > the right equipment One $5 wrench, one $10 filter wrench (optional). One set of ramps ($40), or jack stands ($30) if you already have a jack. One drain pan, $10 (or free if you're resourceful). Total cost max $65. Cheaper if you look for deals, buy used, bor…
Given the number of SUVs and trucks, many people don't even need these.
Also detonated the payload: https://leitwacht.eu/blog/valid-provenance-malicious-package
Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…
> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.