PyTorch and the PyPI supply chain

Posted Jan 12, 2023 15:37 UTC (Thu) by rgmoore (✭ supporter ✭, #75)
In reply to: PyTorch and the PyPI supply chain by mathstuf
Parent article: PyTorch and the PyPI supply chain

I don't know if waiting for the distributions to package everything is the right solution. I'm inclined to believe developers who say it's unlikely to work for them, if only because of the problem you highlight of there being too many libraries to package. I also believe, though, that the current solution of grabbing whatever is out there, trusting it's fine, and then acting surprised by supply chain attacks is also not working. It's just resulting in occasional spectacular failures rather than regular, boring unavailability of bug fixes and product enhancements.

What is needed is a system that provides some kind of real quality control, so developers can have a confidence the libraries they're using are what it says on the tin. This has the unfortunate side effect of slowing everything down for the QC step, but the alternative is occasionally getting pwned when attackers finally decide your system is worth attacking. Pretending everything is fine in an attempt to go as fast as possible is demonstrably not working.

to post comments

PyTorch and the PyPI supply chain

Posted Jan 12, 2023 17:22 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

We need to be able to have quality control somewhere, the question is if PyPI is the organisation to do it. What I'm thinking is a kind of meta-index where different organisations can give a "trust rating" or something, and that I can filter on that in pip.

For example, it would be possible for someone to write a bot that checked if the contents of the wheels distributed by PyPI match the source in the indicated repository. The problem is there is nowhere to place this information in a way that is of any use. Or, it would be nice to straight up reject any package that has existed for less than 3 months. Or being able to namespace dependencies to ensure they come from the right repository.

Python is here paying the decision early on that no packaging/repository standard would be made and to let the community create one organically. It's biting back hard now. More recent languages did not repeat that mistake.

PS. Don't talk to me about solutions like Nexus which try to solve the problem on the client-side but don't really have any extra information to work with and so just end up adding an extra layer of frustration. Until the necessary information is available in machine readable form no client-side tooling can help.

PyTorch and the PyPI supply chain

Posted Jan 13, 2023 4:01 UTC (Fri) by pabs (subscriber, #43278) [Link]

I feel like distributed code review ala crev, along with reproducible and bootstrappable builds is the right model here.

https://github.com/crev-dev/
https://reproducible-builds.org/
https://bootstrappable.org/

PyTorch and the PyPI supply chain

Posted Jan 18, 2023 1:15 UTC (Wed) by hazmat (subscriber, #668) [Link] (1 responses)

re distros, too much plurality and too much complexity to get across the swathe when viewed in aggregate for a developer/publisher of a python dependency, ie language tools exist for a reason. i'd be willing to settle for simple signature upload and verification (sans gpg, say cosign) on the language repos.. but there has been a slow moving effort to try and make things better albeit glacial speeds.. https://blogs.vmware.com/opensource/2020/09/17/tuf-pypi-i... updates are scattered across internet/github issues / tulip chat logs. i do wonder if some of the ossf projects will help on the broader ecosystem. its unclear if we're not just creating another checkbox for enterprises sometimes vs actually moving the needle.

PyTorch and the PyPI supply chain

Posted Jan 18, 2023 15:34 UTC (Wed) by hazmat (subscriber, #668) [Link]

found the best link for current state at
https://github.com/pypi/warehouse/issues/10672