131–140 of 894 posts
Earlier quoted context omitted.
About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.
timeoutMs is shorter ;) You guys can't appreciate a bad joke
Earlier quoted context omitted.
Because no other language has ever had supply chain attacks ever, in history. Nope. https://blog.rust-lang.org/2022/05/10/malicious-crate-rustde... https://en.wikipedia.org/wiki/Log4Shell https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-an... https://about.gitlab.com/blog/gitlab-catches-mongodb-go-modu... https://www.reversinglabs.com/blog/packagist-php-repo-supply...
Log4Shell was hardly a supply-chain attack - just a latent bug in a widely-used library. That can happen anywhere. Maven to this day represents my ideal of package distribution. Immutable versions save so much trouble and I really don't understand why, in the age of left-pad, other people looked at that and said, "nah, I'm good with this."
Most package.jsons I see have semver operators on every dependency, so patches spread incredibly quickly. Package namespacing is not enforced, so there is no way of knowing who the maintainer is without looking it up on the registry first; for this reason many of the most popular packages are basically side projects maintained by a single developer*. Post-install scripts are enabled by default unless you use pnpm or bun.
When you combine all these factors, you get the absolute disaster of an ecosystem that NPM is.
*Not really the case for Axios as they are at least somewhat organized and financed via sponsors.
PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…
The config for uv won't work. uv only supports a full timestamp for this config, and no rolling window day option afaik. Am I crazy or is this llm slop?
> Define a dependency cooldown by specifying a duration instead of an absolute value. Either a "friendly" duration (e.g., 24 hours, 1 week, 30 days) or an ISO 8601 duration (e.g., PT24H, P7D, P30D) can be used.
Earlier quoted context omitted.
If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.
I suspect most packages will keep a mix of people at 7 days and those with no limit. That being said, adding jitter by default would be good to these features.
This became evident, what, perhaps a few years ago? Probably since childhood for some users here but just wondering what the holdup is. Lots of bad press could be avoided, or at least a little.
Package managers are a failed experiment. We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size. The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majori…
But maybe that's not the right fit either. The world where package managers are just open to whatever needs to die. It's no longer a safe model.
Earlier quoted context omitted.
[flagged]
Cargo is a great package manager and hasn't suffered from the same problems. I'll take it.
Does cargo contain any mitigations to prevent a similar attack?
Now hopefully no distro signing keys have been compromised in the latest attacks...
PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…
The config for uv won't work. uv only supports a full timestamp for this config, and no rolling window day option afaik. Am I crazy or is this llm slop?
Earlier quoted context omitted.
An alternative: - copy the dependencies' tests into your own tests - copy the code in to your codebase as a library using the same review process you would for code from your own team - treat updates to the library in the same way you would for updates to your own code Apparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should've be…
I don't know where you've worked but a hostile and intelligent actor or internal red team would succeed under each of those cases at every job I've worked at.
Earlier quoted context omitted.
About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.
timeoutMs is shorter ;) You guys can't appreciate a bad joke
PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…
> (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.) First day with javascript?