771–780 of 1001 posts
Earlier quoted context omitted.
> There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development" What kind of code does this developer write?
As little code as possible to get the job done without enormous dependencies. Avoiding js and using css and html as much as possible.
Earlier quoted context omitted.
The blessing and curse of frontend development is that there basically isn't a barrier to entry given that you can make some basic CSS/JS/HTML and have your browser render it immediately. There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"
> There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development" What kind of code does this developer write?
It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies. This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package…
I'm also wondering why huge scale attacks like this don't happen for other package managers. Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed. Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc... Like, there is the post install script issue or c…
I've always worked at companies where we use third party open source libraries utilities and its true that they get less-than-ideal amount of auditing when they get updated but at least we're not constantly pushing updates of to our customers solely for the sake of using the latest version. In fact usually they're out of date by several years which is also a problem but generally there'll be a guy following the mailing lists for updates in case there's a known exploit that needs to be patched.
Earlier quoted context omitted.
It isn't feasible to audit every line of every dependency, just as it's not possible to audit the full behavior of every employee that works at your company. In both cases, the solution is similar: try to restrict access to vital systems only to those you trust,so that you have less need to audit their every move. Your system administrators can access the server room, but the on-site barista can't. Your HTTP server i…
> It isn't feasible to audit every line of every dependency, just as it's not possible to audit the full behavior of every employee that works at your company. Your employees are carefully vetted before hiring. You've got their names, addresses, and social security numbers. There's someone you're able to hold accountable if they steal from you or start breaking everything in the office. This seems more like having se…
Sounds very similar to how global SIs staff enterprise IT contracts.
I think these kinds of attack would be strongly reduced if js had a strong standard library. If it was provided, it would significantly trim dependency trees of all the small utility libraries. Perhaps we need a common community effort to create a “distro” of curated and safe dependencies one can install safely, by analyzing the most popular packages and checking what’s common and small enough to be worth being inclu…
Earlier quoted context omitted.
Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of. However, pro…
I think the smallest C library I’ve seen was a single file to include on your project if you want terminal control like curses on windows. A lot of libraries on npm (and cargo) should be gist or a blog post.
Earlier quoted context omitted.
A brief but important point is that this primarily holds true in the context of rewriting/vendoring utilities yourself, not when discussing importing small vs. large dependencies. Just because dependencies do a lot more than you need, doesn't mean you should automatically reach for the smallest dependency that fits your needs. If you need 5 of the dozens of Lodash functions, for instance, it might be best to just ins…
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.
Earlier quoted context omitted.
I didn’t downvote, but... Depending on a commercial service is out of the question for most open source projects.
Renovate is not commercial, it's an own source dependabot, quite more copable at that.
I try to stay as far from web development as possible in my programming career (kernel/drivers and most recently reverse engineering) so maybe I'm ill-informed here but this npm thing seems to be uniquely terrible at security and i cannot fathom why the entire web seems to be automatically downloading updates from it and pushing them into production with no oversight. I've always worked at companies where we use thir…
The "blind" auto updating to latest versions seems to be also an issue here, simply you cannot trust it enough as there is (seemingly) no security vetting process (I mean if you get obfuscated gibberish pushed into a relatively sanely written codebase it should ring some alarms somewhere).
Normally you'd run tests after releasing new versions of your website but you cannot catch these infected parts if they don't directly influence the behavior of your functionality.