PyTorch and the PyPI supply chain
PyTorch and the PyPI supply chain
Posted Jan 12, 2023 8:45 UTC (Thu) by ms (subscriber, #41272)In reply to: PyTorch and the PyPI supply chain by koh
Parent article: PyTorch and the PyPI supply chain
I think that certainly helps. But there have also been lots of examples of submitting PRs that get malicious code in to repos; along with social engineering to take over code repos; and e.g. established chrome extensions being sold to a new owner and then malicious code gets injected. In these cases, the name of the repository hasn't changed.
Another thing that helps is getting away from this mantra of "always fetch the latest version that satisfies your semver constraints". If you take the Go approach of _minimal_ version rather than maximal, then the blast radius is much reduced: it is no longer sufficient to release a new compromised version - that on its own will not get picked up. You would also have to modify the deps of a repo that imports that, and of that, and so on, all the way up to the top.
https://research.swtch.com/vgo-mvs (the section on "Upgrade Timing" is most relevant here).
I'm certainly not claiming Go is the only language to do this; it is simply the one with which I'm most familiar.
What I absolutely detest is the attitude that "this is a people problem, we shouldn't try to solve it with technical means". Correct - you won't be able to _solve_ it. But that's not the point. The point is to reduce the probability of these farcical messes from occurring. And there is plenty of prior art out there that helps. Refusing to learn from that is just sticking your head in the sand.
Posted Jan 12, 2023 12:35 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Sounds like cultivation of Log4Shells instead of “dependency confusion”. But yeah, that's definitely fit well into “simple non-solutions” scheme Go practices.
Posted Jan 14, 2023 19:42 UTC (Sat)
by KJ7RRV (subscriber, #153595)
[Link] (2 responses)
Posted Jan 15, 2023 11:14 UTC (Sun)
by farnz (subscriber, #17727)
[Link] (1 responses)
There cannot be a way to specify that an update is a security update without losing any gains from the "minimal version" route; there is no way to distinguish "malicious actor flags version with back door as security update" from "good actor flags version removing back door as security update".
As with so many things, it all comes down to trust. If you trust upstream to release good updates, you want to take their latest code. If you don't trust upstream, you should be locking exact versions, and reviewing every new release upstream manually before you bring it in (which, in turn, has to be your top priority in case the fixes are security relevant to your code).
Posted Jan 15, 2023 12:18 UTC (Sun)
by ms (subscriber, #41272)
[Link]
Both of these are relevant:
> You would also have to modify the deps of a repo that imports that, and of that, and so on, all the way up to the top.
PyTorch and the PyPI supply chain
PyTorch and the PyPI supply chain
PyTorch and the PyPI supply chain
PyTorch and the PyPI supply chain
https://go.dev/blog/vuln
https://go.dev/blog/supply-chain