621–630 of 797 posts
why don't web devs just learn html and css properly, and maybe xslt for the really complex transformations then use vanilla js only when it's truly necessary? instead we've got this absolute mess of bloated, over-engineered junk code and ridiculously complicated module systems.
Earlier quoted context omitted.
Everything runs in the container and cannot escape it. Its like a sandbox. You have to make sure you're not putting any secrets in the container environment.
>You have to make sure you're not putting any secrets in the container environment. How does this work exactly? containers still need env vars and access to databases and cloud environments. Without these the container is just useless isolated pod.
Its not going to stop attacks, but it will limit blast radius a lot.
Earlier quoted context omitted.
I have a perfect set up in inside docker that works. I would love to know why bubblewrap is a superior alternative. Here's mine https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849...
My understanding is that docker escapes are not all that difficult, and your aliases really aren’t doing much to harden the container. but I am not an expert on the matter. I’m sure there is plenty of info online
1. Show me how you would escape Docker
2. Show me npm packages doing this in the wildEarlier quoted context omitted.
wait, I short-circuited here. wasn't the very concept of "libraries" created to *not* have to think about what exactly the code does? imagine reviewing every React update. yes, some do that (Obsidian claims to review every dependency, whether new or an update), but that's due to flaws of the ecosystem. take a look at Maven Central. it's harder to get into, but that's the price of security. you have to verify the name…
> Go is also nice in that regard - you are depending on Git repositories directly, so you have to hijack into the Git repo permissions and spoil the source code there. That in itself is scary because Git refs are mutable. Even with compromised credentials, no one can replace artifacts already deployed to Maven Central, because they simply don't allow it. There is nothing stopping someone from replacing a Git tag with…
Run npm and yarn inside docker [1]. Infact, do this for all risky tools[2] 1 - https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849... 2 - https://ashishb.net/programming/run-tools-inside-docker/
I think it's better to not run npm as root user on container. I would suggest adding --user 1000 to your docker run command.
Good point. Here's the improvement that work for me
https://github.com/ashishb/dotfiles/commit/fe4fb15fe867bf77a...
ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
> And of course make a very limited scope publisher key, bind it to specific packages (e.g. workflow A can only publish pkg A), and IP bound it to your self hosted CI/CD runners. No one should have publish keys on their local, and even if they got the publish keys, they couldn't publish from local. I've by now grown to like Hashicorp Vaults/OpenBao's dynamic secret management for this. It's a bit complicated to under…
Earlier quoted context omitted.
wait, I short-circuited here. wasn't the very concept of "libraries" created to *not* have to think about what exactly the code does? imagine reviewing every React update. yes, some do that (Obsidian claims to review every dependency, whether new or an update), but that's due to flaws of the ecosystem. take a look at Maven Central. it's harder to get into, but that's the price of security. you have to verify the name…
> Go is also nice in that regard - you are depending on Git repositories directly, so you have to hijack into the Git repo permissions and spoil the source code there. That in itself is scary because Git refs are mutable. Even with compromised credentials, no one can replace artifacts already deployed to Maven Central, because they simply don't allow it. There is nothing stopping someone from replacing a Git tag with…
ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
Npm is what happens when you let tech debt stack up for years too far. It took them five attempts to get lock files to actually behave the way lock files are supposed to behave (lockfile version 3, + at least 2 unversioned attempts before that). It’s clear from the structure and commit history they’ve been working their asses off to make it better, but when you’re standing at the bottom of a well of suck it takes tha…
I wonder what circumstances led to saying “this is okay we’ll ship it like that”
Earlier quoted context omitted.
But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.
That worried me too, a sort of inverse tragedy of the commons. I'll use a weeklong cooldown, _someone else_ will find the issue... Until no-one does, for a week. To stretch the original metaphor, instead of an overgrazed pasture, we grow a communally untended thicket which may or may not have snakes when we finally enter.
The "until no one does" is not something that can happen in something like npm ecosystem, or even among the specific user of "left-pad".
Earlier quoted context omitted.
> Because updates don't just include new features but also bug and security fixes. This practice needs to change, although it will be almost impossible to get a whole ecosystem to adopt. You shouldn’t have to take new features (and associated new problems) just to get bug fixes and security updates. They should be offered in parallel. We need to get comfortable again with parallel maintenance branches for each major…
Semver was invented to facilitate that. Only if everyone adhered to it.