Re:GitHub’s database of security advisories is now open source
by pabs3 on Sunday February 27, 2022 @01:54AM
(#30486039)
Personally, I'd stop vendoring dependencies and stop checking lock files into git and use version ranges instead. That way people always get the latest CVE fixes when they use the software. Then have good automated testing so that if one of the dependencies breaks something, it gets flagged quickly.
[ Parent
| on HN ]
Re:GitHub’s database of security advisories is now open source
by jonathanlydall on Sunday February 27, 2022 @02:52AM
(#30486284)
Lock files enable reproducibility of “builds”.
For example, if there is a reported problem in production, with lock files I can check out the same commit and be able reproduce (if the provided steps are correct).
Without lock files one or more dependency versions might be higher on my machine than production and then I don’t know if failure to reproduce is because of the steps I’m trying or because the problem doesn’t exist in the updated dependencies.
And then because not all package maintainers are good about following semantic versioning, the build on the CI server can sometimes break itself due to dependency updates which aren’t backwards compatible.
Version range dependencies seem like a nice solution, but in practice I’ve found them to be a nightmare.