Comment by henning
1 year ago
I automatically don't want to use this database because the number of third party dependencies are an unfixable, never-ending source of security vulnerabilities.
1 year ago
I automatically don't want to use this database because the number of third party dependencies are an unfixable, never-ending source of security vulnerabilities.
Sometimes I'm pretty sure people upvote stories just to see what happens in the comments.
Guilty as charged. To steal a phrase from Reddit, "the true LPT is in the comments"
The true insightful discussion comes in the comments.
LPT?
1 reply →
Guilty as charged.
Yes, the amount of effort it takes to audit dependencies scales roughly linearly, so unless you're going to blindly install them, choosing to use a project with so many dependencies means taking on a tremendous amount of ongoing work.
> the amount of effort it takes to audit dependencies scales roughly linearly
With the lines of code, not the number of dependencies. 10 dependencies of 100 lines of code are arguably easier, but certainly not harder than a single dependency of 1000 lines of code.
I should clarify that I mean auditing dependency-publisher authentication, rather than full code review.
This returns us to status quo ante, back before supply chain attacks were something we worried about. Bugs and such from dependencies are an annoyance but a manageable problem. Supply chain attacks after publisher account compromise are catastrophic and are not manageable.
3 replies →
Nowadays this applies to everything that depends on modules that depend on more modules (e.g. NodeJS).
yeah, rust copied the dumpster fire that was npm, i shudder to think of the future of supply chain security when people say rewrite it in rust.
I'm pretty sure everybody just copied from Perl.
Go did something nice, and it would be good if more people copied. But it was also fairly recent.
Almost - CTAN (T for "TeX") predated CPAN by about 1 year (but may not have ever had as much automated fetching involved).
What would a better model to manage dependencies in your opinion? I do like that is easy to add dependencies, but also don't like that a simple hello world Axum app IIRC is around 150 dependencies.
Rust's problems are not necessarily dependency management, cargo is actually great at it, but that they rely on third party dependencies for critical components (like regex and async). Which makes it very difficult to build anything without 300 dependencies.
I understand why they do it. It's lead to some amazing crates like serde. But I think I fall more in the camp of Python, Go or Odin with a comprehensive standard lib. You can make a whole game with Odin with standard library only. Or an entire web app in Go.
2 replies →
have an ecosystem that encourages larger, more well thought out dependencies.
the thin standard library and flat package namespace encourages land grabs for short memorable names for packages that just do a single thing. compared to say java or go where dependencies don't exist because they sound cool but because they solve a real problem.
You don't have to have a solution to recognize that there is a problem.
3 replies →