31–40 of 152 posts
This for instance will only install packages that are older than 14 days:
uv sync --exclude-newer $(date -u -v-14d '+%Y-%m-%dT%H:%M:%SZ')
It's great to see this kind of stuff being adopted in more places.
I know it would take time for packages to adopt this but it could be implemented as parameters when installing a new dependency, like `npm i ping --allow-net`. I wouldn't give a library like chalk access to I/O, processes or network.
I think uv should get some credit for being an early supporter of this. They originally added it as a hidden way to create stable fixtures for their own tests, but it has become a pretty popular flag to use. This for instance will only install packages that are older than 14 days: uv sync --exclude-newer $(date -u -v-14d '+%Y-%m-%dT%H:%M:%SZ') It's great to see this kind of stuff being adopted in more places.
It would also be nice to have this as a flag so you can use it on projects that haven't configured it though, I wonder if that could be added too.
I might be naive but why isn't any package manager (npm, pnpm, bun, yarn, ...) pushing for a permission system, where packages have to define in the package.json what permission they would like to access? À la Deno but scoped to dependencies or like mobile apps do with their manifest. I know it would take time for packages to adopt this but it could be implemented as parameters when installing a new dependency, like…
You might be able to do this around install scripts, though disk writing is likely needed for all (but perhaps locations could be controlled).
Should have included the units in the name or required a choice of unit to be selected as part of the value. Sorry, just a bugbear of mine.
The new setting is consistent with the old ones, which is more important IMHO: https://pnpm.io/settings#modulescachemaxage
I might be naive but why isn't any package manager (npm, pnpm, bun, yarn, ...) pushing for a permission system, where packages have to define in the package.json what permission they would like to access? À la Deno but scoped to dependencies or like mobile apps do with their manifest. I know it would take time for packages to adopt this but it could be implemented as parameters when installing a new dependency, like…
I feel like that would require work from the language side, or at least runtimes. Is there a way of stopping code in one package from, say, hitting the network? You might be able to do this around install scripts, though disk writing is likely needed for all (but perhaps locations could be controlled).
Yeah, it needs work from the language runtime, but I think even a hacky, leaky 'security' abstraction would be helpful, because the majority of malware developers probably aren't able to break out of a language-level sandbox, even if the language still allows you to do unsafe array access.
Then we can iterate.
Earlier quoted context omitted.
The Politician's Syllogism[0] is instructive. [0] https://en.wikipedia.org/wiki/Politician's_syllogism
OK, we are here now on reddit or facebook? I thought we discuss here problems and possible solutions. My fault.
There's an open discussion about adding something similar to bun as well^
minimumReleaseAge doesn't seem to be a bulletproof solution so there's still some research/testing to be done in this area
If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.
2) Real chances for owners to notice they have been compromised
3) Adopt early before that commons is fully tragedy-ed.
But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use.
That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to create juicy attack surface around the resolution of that name to some bits.