|
|
Subscribe / Log in / New account

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

> To me the solution is pretty simple and nothing that hasn't been implemented elsewhere: identify the repository in the dependency specification.

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.


to post comments

PyTorch and the PyPI supply chain

Posted Jan 12, 2023 12:35 UTC (Thu) by khim (subscriber, #9252) [Link]

> 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.

Sounds like cultivation of Log4Shells instead of “dependency confusion”.

But yeah, that's definitely fit well into “simple non-solutions” scheme Go practices.

PyTorch and the PyPI supply chain

Posted Jan 14, 2023 19:42 UTC (Sat) by KJ7RRV (subscriber, #153595) [Link] (2 responses)

Doesn't using the minimum version instead of maximum result in not receiving security updates for dependencies until the depending package is also updated? That seems like a much worse outcome for security, especially considering dependencies of dependencies, etc. Or does Go have a way of specifying that an update is a security update?

PyTorch and the PyPI supply chain

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).

PyTorch and the PyPI supply chain

Posted Jan 15, 2023 12:18 UTC (Sun) by ms (subscriber, #41272) [Link]

Exactly. There is tooling to help find vulnerabilities, but yes, the basic premise is that you the developer must explicitly give permission for some dependency (even transitively) to be updated. Doing anything less gated than this is really just giving other developers permission to execute arbitrary code on your machine.

Both of these are relevant:
https://go.dev/blog/vuln
https://go.dev/blog/supply-chain


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds