rfcs
rfcs copied to clipboard
yarnpkg
Proposal to provide package safety check
Yeah, static analysis isn't doable in Javascript (unless we talk about a super strict subset of JS), and would be kinda out of scope for Yarn.
@ljharb Btw, has the Node project ever considered working on a secure sandbox model for Node? More things would become possible, like restricting requires for some modules in such a way that they wouldn't be able to access fs, http(s), or any other builtin that would expose the system. It could be opt-in based on settings in the package.json (with the understanding that fs access would basically be "all permissions", of course).
Much simpler proposal would be: It appears one of the reason why eslint-scope created issues is because currently there doesn't seems to be a way to disable a package, and many package.json does not pin minor version. Would it be possible to maintain a public list of compromised packages, so people would be warned if they try to upgrade to that version? It could be an opt-in. or allow people to supply such list created by their team, or within company
This doesn't make any decision on how safefy-check are done, but simply a way to mark them unsafe to use in a team, organization, company, or globally if the user choose to use the global list.
There’s an open PR exploring it now, i believe.
Seems to be https://github.com/nodejs/node/pull/22112. Nice! I wonder if it could be integrated with Yarn so that we could print a "are-you-sure" prompt at install time?
It appears one of the reason why eslint-scope created issues is because currently there doesn't seems to be a way to disable a package, and many package.json does not pin minor version
I'm not sure it was the issue - the compromised package was swiftly removed from the npm registry, so it became unavailable as soon as it was detected. A blacklist wouldn't have been much faster.
I suppose such a feature wouldn't hurt (I heard it being suggested a few times already), the main issue I have with it is that it would make yet another thing to maintain.
@arcanis I assumed so as it appears there are pull-requests to many libraries to revert the update of eslint-scope. I wasn't exactly sure of the timing by reading the post-mortem published by eslint team.
Combining those thoughts, it strikes me that instead of a blacklist, can we have some sort of whitelist? like a for signatures on packages? For example, maintainers can sign package hash with their GPG key, and post it to the list. and people can create bots to sign those packages too.
The benefit of such approach is that Instead of passive response towards incidents, the process requires active signing. And it would enable customized policies for project owner, say the project owner can configure that a package release will only be available to public if they pass certain bot checks i.e. receiving signatures from those bots/or just certain human. And company can enforce policy where a package must have the signatures of their security team or certain someones to be used with the internal packages.
This can be optionally configured at the cli end. It can also be configured to rely on multiple signatures. it might happen that one person's key get compromised and package get published, and is much more unlikely that multiple person's key got compromised at the same time.
It has more advantages over a blacklist as a blacklist must be maintained by someone/or team, and the proposed network of signature can be maintained distributed.
Wonder your thoughts on this.
:)
That kind of whitelist would stifle growth of the ecosystem and enormously privilege existing maintainers; that imo is also a nonstarter.
My 2 cents.
Having experimented with utilising macOS’ sandbox facility to sandbox CocoaPods installations, my takeaways are that it is hard to get right and moreover many ideas about securing the installation phase are alas futile.
I may be overlooking something unique to npm/yarn, but as long as you eventually end-up executing the code un-sandboxed then there’s really no point in securing the installation too much. Focussing only on the installation phase is unfortunately mostly security theatrics.
A holistic proposal such as https://github.com/nodejs/node/pull/22112 makes a ton of sense to me, as long as it applies to both installation and execution phases.
