101–110 of 122 posts
Glad to see this article raising awareness. Without fairness in the marketplace, the talent loses the will to play and the economy will further deteriorate. We are all suffering from an international trust breakdown from Covid, and now also from AI spam. If we don’t turn this tide, jobs and business opportunities are going to keep shrinking.
Seems like people already forgot about Jia Tan. By the way why doesn't npm have already a system in place to flag sketchy releases where most of the code looks normal and there is a newly added obfuscated code with hexadecimal variable names and array lookups for execution...
Earlier quoted context omitted.
I'm often curious about how effective runtime quasi-sandboxing is in practice (at least until support at the TC39 level lands). My understanding is that if you can run with a CSP that prevents unsafe-eval, and you lock a utility package down to not be able to access the `window` object, you can prevent it from messing with, say, window.fetch. But what about a package that does assume the existence of window or global…
It's based on HardenedJS.org The sandbox itself is tight, there's a bug bounty even. The same technology is behind metamask snaps - plugins in a browser extension. And Moddable has their own implementation The biggest problem is endowing too powerful capabilities. We've got ambitious plans for isolating DOM, but that already failed once before.
Earlier quoted context omitted.
That would flag a huge percentage of JS packages that ship with minified code.
How are people verifying their dependencies if they are minified?
Earlier quoted context omitted.
How are people verifying their dependencies if they are minified?
My guy… in the JS ecosystem a “lock file” is something that restricts your package installer to an arbitrary range of packages, i.e. no restrictions at all and completely unpredictable. You have to go out of your way to “pin” a package to a specific version.
Earlier quoted context omitted.
My guy… in the JS ecosystem a “lock file” is something that restricts your package installer to an arbitrary range of packages, i.e. no restrictions at all and completely unpredictable. You have to go out of your way to “pin” a package to a specific version.
Lockfiles use exact hashes, not versions/version ranges. Javascript projects use two files, a package file with version ranges (used when upgrading) and a lockfile with the exact version (used in general when installing in an existing project).
Earlier quoted context omitted.
My guy… in the JS ecosystem a “lock file” is something that restricts your package installer to an arbitrary range of packages, i.e. no restrictions at all and completely unpredictable. You have to go out of your way to “pin” a package to a specific version.
Lockfiles use exact hashes, not versions/version ranges. Javascript projects use two files, a package file with version ranges (used when upgrading) and a lockfile with the exact version (used in general when installing in an existing project).
The best way to manage JS dependencies is to pin them to exact versions and rely on renovate bot to update them. Then at least it’s your choice when your code changes. Ideally you can rebuild your project in a decade from now. But if that’s not possible then at least you should have a choice to accept or decline code changes in your dependencies. This is very hard to achieve by default in the JS ecosystem.