881–890 of 894 posts
Earlier quoted context omitted.
^ Vibe-coded slop spam ^
What makes you think that? Your can see the commit history Rest was all written by me. Unlike other criticisms of the project, this one feels personal as it is objectively incorrect.
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…
~/.npmrc
min-release-age=7 # daysEarlier quoted context omitted.
Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…
This looks like an ad for batteries included to me. Libraries also don't get it right the first time so they increment minor and major versions. Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON? The benefits are worth it judging by how ubiquitous Go, Java and .NET are. I'd rather leverage billions of support paid by the likes of Google, Oracle and…
Earlier quoted context omitted.
The HTML "Living Standard" is constantly updated [1-6]. The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025. The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development. The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions. The schema.org metadata standard [10] is und…
please! nobody uses Xpath (coz json killed XML), it RDF (semantic web never happened, and one ever 10years is not fast), schema.org (again, nobody cares), PNG: no change in the last 26 years, not fast. the HTML "living standard" :D completely optional and hence not a standard but definition.
Earlier quoted context omitted.
Glad to see that Clamscan experiment worked. Keep me updated on the continued testing and I am glad that my archival efforts are appreciated :)
absolutely massive help. i love HN community and thanks. If you do see an archive of axios or other compromised artifacts, please send those my way for continued testing. i'm going to test automation and see if this actually has utility.
And I love HN community too and your welcome!
Earlier quoted context omitted.
Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…
For me, the v2 re-writes, as well as the "x" semi-official repo are a major strength. They tell me there is a trustworthy team working on this stuff, but obviously not everything will always be as great as you might want, but the floor is rising.
Earlier quoted context omitted.
absolutely massive help. i love HN community and thanks. If you do see an archive of axios or other compromised artifacts, please send those my way for continued testing. i'm going to test automation and see if this actually has utility.
Hey tony, sorry I had read your comment, I was a little busy. I will try to do something about axios tomorrow to help you out! And I love HN community too and your welcome!
https://github.com/extremeshok/clamav-unofficial-sigs/tree/m...
Earlier quoted context omitted.
Come on dude. The issue is the frequency and magnitude of these attacks. Log4Shell was also not a supply chain attack. I looked at the Rust one for example, which is literally just a malicious crate someone uploaded with a similar name as a popular one: > The crate had less than 500 downloads since its first release on 2022-03-25, and no crates on the crates.io registry depended on it. Compared to Axios, which gets 8…
What exactly do you think the argument is? The issues have everything to do with npm as a platform and nothing with JS as a language. You can use JS without npm. Saying you'll escape supply chain attacks by not using JS is like saying you'll be saved from an car crash with a parachute.
Earlier quoted context omitted.
but wouldn't it work in this case? sure if a package was compromised for months/years it wouldn't save you but tell dependabot to delay a week, you'd sleep easy from this nonesense
slowly walking through a minefield isn’t any safer than running. So unless you’re saying the extra time will be spent inspecting every package, whenever you do update, you will be getting an insecure package. You’re not safe by dodging axios. There are currently thousands of breached packages ready to install that aren’t notable. “I’ll run npm install after checking twitter” won’t help
Earlier quoted context omitted.
> making the lockfiles more complicated? Poor phrasing; I meant the attacks. Now you don’t just have a lockfile you need to sneakily modify, and the diff grows. As to your second point, yes. It’s really a different feeling when you add one more package and suddenly have 215 new files to check in!
> suddenly have 215 new files to check in! How big is your repo, if I may ask? Personally I store vendored dependencies in a submodule, where I can squash history, if it grows too large.
It’s a subjective question, but in one of the zero-installs projects I definitely remember that when I added a couple of particular GUI libraries there suddenly a very, very long list of new files to track, since those maintainers to keep things decoupled. I wouldn’t stop using that library at that point (there were deadlines), but I would definitely try to find something lighter or more batteries-included next time.
There can be a tiny project with just one dependency that happens to have an overgrown, massive graph of further transitive dependencies (a very unpleasant scenario which I would recommend to avoid).
With zero installs turned on, such a codebase could indeed qualify as “big repo”, which I think would reflect well its true nature.
Without zero installs it could be tiny but with a long long lockfile that nobody really checks when committing changes.
> Personally I store vendored dependencies in a submodule
I don’t like the added mental overhead of submodules, and so prefer to avoid them when possible, which I guess is a subjective preference.
Since this is, coneptually speaking, the matter of package management more so than it is the matter of version control in genetal, I prefer to rely on package manager layer to handle this. I can see how your approach could make sense, but honestly I would be more anxious about forgetting something when keeping vendored dependencies up-to-date in that scenario.
Your approach could be better in a sense that you can spot-check not just the list of changed packages, but also the actual code (since you presumably vendor them as is, while Yarn checks in compressed .tgz files). Not sure whether that justifies the added friction.