What do you think about crev ?

[GrosSacASac]

Project page: https://github.com/crev-dev/crev/

[wesleytodd]

I have no opinion, and what is documented there is really not enough to form them. Is there something more you hope to see from us on this question? If so could you maybe provide more context or links?

[ghinks]

What I do find interesting is that quite organically many people are coming to similar conclusions about aligning on best practices and rules for open source in general. This is the first I have heard of crev. I applaud the idea. However I feel that we may be better served by joining into existing endeavors rather than starting new ones.

[GrosSacASac]

What else is already existing ?

Right now as a package maintainer the only safe way to update a dependency (correct me if I am wrong) is to install it with --ignore-scripts and carefully read the code, and all it's dependencies (if they changed). With crev we could share the fact that [email protected] is safe and reviewed. So then if I trust my coworker and he reviewed a dependency for another project I could then reuse that review in a nice cli.

I am opening this issue because crev does seem to solve the problem on how to create a database of reviewed package which we need in npm.

The crev implementation for npm could need some help.

Related: #280

[wesleytodd]

There are many ways we might improve the story around security of packages. I think having a a review tool would be a great addition! It does not solve all things, but if you can get enough eyeballs looking it really helps!

As for what the WG can help with, I am not sure that project is mature enough to have us recommend it yet, as the docs are slim and really only cover what looks like a text format. Maybe if it reaches more maturity we could spend some time reviewing it to see if it might be a good fit for what we are recommending to package maintainers.

[ljharb]

@GrosSacASac you can audit a dependency without installation, both by using https://unpkg.com or by downloading the tarball directly and exploring it.

[dominykas]

I've been thinking of similar ideas at the start of the year, when the event-stream incident was still fresh. Yes, the only way to trust code you're importing is to either write it yourself (although I don't necessarily trust myself that much) or to review it (but do you really grok the package from just the diff? what about something like babel? how RMS do we go on this - do we review V8 upstream?) or to offload that to an external audit/reviewer (but who will review the reviewers?). And yes, there is probably some need for tooling/processes/services around that in the overall market.

That said, it's unfeasible to review all the code that you're using as a business (i.e. there has to be some implied trust) - let alone all the code you're importing as an OSS developer. I think we do have an issue to write up best practices for choosing packages (or are we mentioning that already)? I already started on #280 and I'll make sure to include a note on the security implications of blind updates.

So I think crev is an interesting tool and it goes in the right direction, but I do think it's a bit early, and the node repo for it seems a bit inactive (but maybe it's supposed to be that way?). And I hope there will be other similar tools and companies to provide competition and innovation.

Given this issue is about a specific tool - shall we close it? And if there's desire to discuss further - re-open a new one, describing the problem and the solutions in more detail and abstract?

[GrosSacASac]

There is also npmfs.com to see deltas between versions.
For example https://npmfs.com/compare/utilsac/10.1.0/10.2.0/