761–770 of 1001 posts
Earlier quoted context omitted.
One downvote is not enough.
One upvote is not enough. We need enough upvotes to fix the problem. You can’t shape a big pile of shit into success. HTTP and JS will never serve as a proper application framework.
Earlier quoted context omitted.
This looks good! Unfortunately it looks like it also suffers from exactly the same software supply chain problem that we need to avoid in the first place: https://github.com/Wilfred/difftastic/blob/master/Cargo.lock Edit: also, consider how much of https://github.com/Wilfred/difftastic/commits/master/ is just noise in itself. 15k commits for a project that appears to only be about four years old.
"exactly the same software supply chain problem" While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified. There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from maintainers like this one[1] from just a few days ago would not happen with cr…
FWIW npm used to allow unpublishing packages, but AFAIK that feature was removed in the wake of the left-pad incident [1]. Altho now with all the frequent attacks, it might be worth considering if ecosystem disruption via malicious removal of pacakge would be lesser of two evils, compared to actual malware being distributed.
As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
You can do this with npm (since version 6.9.0).
To only get registry deps that are over a week old:
$ npm install --before="$(date -v -7d)"
As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
Personally, I go further than this and just never update dependencies unless the dependency has a bug that affects my usage of it. Vulnerabilities are included. It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature t…
This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…
Linux distros could still stand to improve here in a bunch of ways, and it seems that a well-designed package ecosystem truly doesn't need such hooks at the level of the package manager at all. But this kind of auditing is one of the useful functions of downstream software distros for sure.
Earlier quoted context omitted.
JS's issue is that it allows you to run an objectively wrong code without throwing explicit error to the user, it just fails silently or does something magical. Seems innocent, until you realize what we use JS for, other than silly websites or ERP dashboards. It is full of gotchas that serves 0 purpose nowadays. Also remember that it is basically a Lisp wearing Java skin on top, originally designed in less than 2 wee…
> JS's issue is that it allows you to run an objectively wrong code without throwing explicit error to the user, it just fails silently or does something magical. Seems innocent, until you realize what we use JS for, other than silly websites or ERP dashboards. What some people see as a fault, others see as a feature :) For me, that's there to prevent entire websites from breaking because some small widget in the bot…
TS is just too much overhead for the marginal gains.
Letting upstream authors write code that the package manager runs at install time isn't a sane thing for package managers to allow. It promotes all kinds of hacky shit and makes packages harder to work with programmatically, and it also provides this propagation vector. Packages also shouldn't have arbitrary network access at build time for both of those two same reasons! There's been a lot of talk here about selecti…
Earlier quoted context omitted.
"rewrite every single dependency from scratch" No need to. But also no need to pull in a dependency that could be just a few lines of own (LLM generated) code.
>>a few lines of own (LLM generated) code. ... and now you've switched the attack vector to a hostile LLM.
A few lines of code can be audited.
Earlier quoted context omitted.
Lucky you. I keep coming back to it because jobs and even for desktop apps a native webview beats everything else. We fcked up with js, big time and its with us forever now
I was hyped for wasm because i thought it was supposed to solve this problem, allowing any programming language to be compiled to run in browsers. But apparently they only made it do like 95% of what JS does so you can't actually replace js with it. To me it seems like a huge blunder. I don't give a crap about making niche applications a bit faster, but freeing the web from the curse of JS would be absolutely huge. A…
Any attempt to bypass this will be perilous.