Design package management security

[dcecile]

Research

• https://hypirion.com/musings/a-resilient-git-dependency-algorithm
• https://snyk.io/blog/yarn-is-micro-secure/
• https://news.ycombinator.com/item?id=18979596
• https://github.com/yarnpkg/yarn/issues/6953
• https://gapintelligence.com/blog/2018/yarn-plug-n-play-vs-node_modules
• https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-plug-an-play.md
• https://kerkour.com/rust-crate-backdoor/
• https://research.swtch.com/npm-colors
• https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/
• https://snyk.io/blog/why-npm-lockfiles-can-be-a-security-blindspot-for-injecting-malicious-modules/
• https://research.swtch.com/vgo-mvs
• https://www.b-list.org/weblog/2022/jul/11/pypi/
• https://lucumr.pocoo.org/2022/7/9/congratulations/

Ideas

• Only from GitHub (Gitlab? Bitbucket?) repos with 2FA required
• Fork (& update as needed) all transitive dependencies, using GitHub (or other) APIs
  • Also needed: system that serves as backup for all GitHub repos for a user/org
• How does Go version selection relate to lockfile security?
• Web of trust
  • Snyk mentions trusting/distrusting specific maintainers, but that's an NPM concept and not especially clear there
  • It would make sense to subscribe to whitelists & blacklists for specific published versions
    • Assuming you trust the list author to review the version diffs
    • This is the most reliable way to
  • For specific maintainers, the Arch model would work with signed tags and/or signed commits
    • Probably the most complete way to trust live-updated whitelists & blacklists