|
| ▲ | chuckadams 9 hours ago | parent | next [-] |
| Got any pointers on how to configure this for yarn? I'm not turning anything up in the yarn documentation or in my random google searches. npm still seems to be debating whether they even want to do it. One of many reasons I ditched npm for yarn years ago (though the initial impetus was npm's confused and constantly changing behaviors around peer dependencies) |
| |
| ▲ | baobun 6 hours ago | parent | next [-] | | Yarn is unfortunately a dead-end security-wise under current maintainership. If you are still on yarn v1 I suggest being consistent with '--ignore-scripts --frozen-lockfile' and run any necessary lifecycle scripts for dependencies yourself. There is @lavamoat/allow-scripts to manage this if your project warrants it. If you are on newer yarn versions I strongly encourage to migrate off to either pnpm or npm. | | |
| ▲ | jrochkind1 4 hours ago | parent [-] | | newer yarn versions are _less_ secure than the ancient/abandoned yarn 1? :( Any links for further reading on security problems "under current maintainership"? |
| |
| ▲ | madeofpalk 6 hours ago | parent | prev [-] | | enableScripts: false in .yarnrc.yml https://yarnpkg.com/configuration/yarnrc#enableScripts And then opt certain packages back in with dependenciesMeta in package.json https://yarnpkg.com/configuration/manifest#dependenciesMeta.... |
|
|
| ▲ | progbits 5 hours ago | parent | prev [-] |
| Obviously blocking install scripts is a good thing, but this is just a false sense of security. If you install a package you will likely execute some code from it too, so the malware can just run then. And that is what the next attack will do as everyone starts using pnpm (or if npm blocks it too). |
| |
| ▲ | staticassertion 4 hours ago | parent [-] | | It's not a false sense of security imo. Code often runs in its own environment, for example a container. We're "used to" sandboxing/ isolating runtime code. It's the package installation process that gets less attention. |
|
