Staying up-to-date

[wilsonehusin]

I'm writing this far ahead of the "good time to start implementing". Partly because I would like for ideas to simmer for a while before we go forth, and also because this can get quite complicated.

---

I think the responsible thing to do is for the project to also inform users that at least one of their dependencies has an update. Being so early in the product design phase, we have some time to think through and get this right.

As of today, the lockfile practically acts as "dependency pinning" mechanism — that is, a dependency will remain consistent since its addition until it was manually modified, in which we assume users to verify the new version before propagating the changes throughout the project. This behavior is a form of protection from "auto-update" where a new update may not have been verified yet, and turns out to be an malicious update (one form of "Supply Chain Attack", as the cool kids say).

Pinning dependencies, however, isn't a complete solution to the whole class of vulnerabilities in supply chain attacks. For example, staying behind updates might mean that the project is not addressing Common Vulnerability and Exposures (CVEs) which may exist in older versions of a program.

How should we assist projects in staying up-to-date, safely?

I think we should worry about two things: how can we make it easy and how can we encourage good hygiene.

In making it easy, we can do some version ceiling limit declarations, i.e. "stay within a major version of a release line", often seen in a programming language dependency manager like Ruby's Bundler or Python's PIP. In theory, this can be implemented reasonably by assuming semantic versioning and doing comparisons. However, it feels reckless to do so when an update turns out to be a malicious one.

If and when we have features around "updates", what should / can we do to roll it out more responsibly? Some ideas:

• CVE database: this is my knee-jerk reaction, but it also shifts the relationship of this tool from "tooling" to "service", which I don't think should be the direction we are going towards — it's a full-time job of it's own (heck, billion dollars value project) and I am certainly not a qualified person to do such work today. I would like to explore this solution as last resort.
• Only enable "update" features for packages with signatures: I think this might be a reasonable compromise which hopefully also drives adoption of signing releases (forcing function to the chicken-egg problem). More research certainly needed on my part, but from what I understand today, this protects us from attacks which happened to UAParser.js, but not so much from node-ipc. This also somewhat depends on Verifying signatures #15.

[wilsonehusin]

If we were to support version ranges / release channels, some prior art might be of help.

[wilsonehusin]

I'm reminded today that Kubernetes sub-sub-project: Zeitgeist somewhat accomplishes this. I think it's worth considering ways we can leverage this too.

My concern about Zeitgeist is the large go.mod / go.sum. Since Zeitgeist is more generic than "binary releases", I think we might be able to get away with less code than they do. One alternative is to fork and trim-off aggressively on the "upstream" implementations as we probably only care about GitHub and GitLab for now.