2 ms·
This is right: unless you use exact versions, ideally vendored or cached in a local package server, you do not have even basic reproducibility. However. The r
by jacques_chester 9y ago
This is right: unless you use exact versions, ideally vendored or cached in a local package server, you do not have even basic reproducibility.
However.
The reason people use ranges is because they don't want to handle the administrative burden of tracking upstream changes and updating their software.
The OWASP Top 10 (2017 draft) shows that using known-vulnerable components is a common security weakness in software. Nobody sets out to do this, but the flipside of having access to massive troves of dependencies is that you have dozens, hundreds, perhaps thousands of dependencies you might not know about.
I've worked on Cloud Foundry Buildpacks. A large amount of effort has gone into exactly this problem: tracking upstream versions, pulling new ones immediately, building them and testing them. But it's at varying levels of sophistication.
For some dependencies, you get structured data. NodeJS publish an index.json file[0] which is fairly trivial to keep up with. But for other sources, which I will leave unnamed, it's necessary to do flaky, unreliable HTML parsing to detect new releases. Data about what's been found so far is kept in a ci-robots[1] repo to ensure atomicity and simplicity (I'd prefer a Concourse resource that emits versions one by one, but that's just me).
What's needed is a uniform way to describe available versions of software packages. Uniform across all the major tributaries of versions: package managers, distributions, the works. If it becomes possible, as Buildpacks have after a great deal of effort, to automate fetching and testing new dependencies, then the need for ranges vanishes. You can rely on your CI/CD to run each dependency change through its paces and update the firmly fixed list for you.
[0] https://nodejs.org/dist/index.json https://nodejs.org/dist/index.json
[1] https://github.com/cloudfoundry/public-buildpacks-ci-robots https://github.com/cloudfoundry/public-buildpacks-ci-robots