Hacker News Reader

Comment by rndhouse | Hacker News Reader

I've created Vouch in an attempt to address this problem:

Vouch lets users create and share reviews for NPM packages. Project dependencies can then be checked against those reviews.

Vouch uses extensions to interface with package ecosystems. It's simple to create a new extension. Extensions currently exist for NPM, PyPi, and Ansible Galaxy.

I'm currently working on a website to index known reviews and publish official reviews.

I hope you guys find it useful! Drop by the Matrix channel if you have any feedback to share: #vouch:matrix.org

View on HN

That's not really the solution for this problem, though, which is very specifically when a project maintainer's account gets compromised, so then the bad guys publish a new malicious version of that library that gets picked up by anyone using non-pinned NPM versions (i.e. most everyone).

There are a couple more straightforward ways to do this:

1. Require 2FA, ideally hardware key 2FA, for anyone publishing a package with any sizable following.

2. Make running of preinstall/install scripts opt-in.

3. Make the semantic versioning syntax optionally more restrictive. If I specify I want version ^2.2.1, I'd like to be able to specify that I DON'T want to pull 2.2.2 the moment it becomes available, but perhaps want some amount of latency before pulling that.

2. Make running of preinstall/install scripts opt-in. They already are, npm install --ignore-scripts

What you've written there is literally the definition of opt out.

Reviews in Vouch refer to a particular version of a software package. If a new release is issued by a malicious actor, the new release would require a new review.

But the review process does not need to re-start from scratch. Reviews from other versions can be used to lessen the workload.

On the subject of automatically updating packages: the Vouch dependency analysis can be included in CI. Un-reviewed or review failing dependency updates can be flagged for attention.

Who's reviewing the software package's dependencies?

Each dependency of a software package would have its own separate set of reviews.

Anyone can produce a review using Vouch. Official reviews will also be published in the future.

So every version of every dependency of every package needs a review? It only takes one version of one dependency of any software package to be compromised by supply chain.

Each developer may choose to minimize the software dependency attack surface to a different degree.

Perhaps they would trust a package published by Google without a review. But would require a review before using a package from an indie developer.

Incremental decreses in the attck surface are valuable.

I'd like this to work, but it seems like it relies on packages being statically "good" or "bad" - what happens if a package is legitimately well trusted but then the main dev gets backdoored and a bit of extra code is injected?

That extra code will stand out as not having been reviewed.

Oh, you mean to have reviewers look at every line of every version (at least cumulatively). Yes, that would work, and while the effort is significant I appreciate that it's the effort you'd want regardless so this helps share the load.

That's right! The purpose of Vouch is to continually decrease the cost of the review process with each new review.

Sounds really interesting. I'm kinda scared to use npm right now to be honest. What dangers may be hidden deep in the dependency trees? But is a review of every update then done, because rc used to be a legit package?

A review corresponds to a particular version number. But the review process does not need to start from scratch with each version number increment. Reviews from previous versions can be leveraged to lessen the workload.

> The check command generates an evaluation report of local project dependencies based on available reviews:

Is there an example of a generated report?

Reply on news.ycombinator.com