On 8/27/25 11:08 AM, Michał Górny wrote: > I don't understand how TOFU is related to this. The way I understand > it, it's hierarchical model. The repo hosting key is verified > by the central key, and that key is used to verify artifacts. Plus, > the repository URL is verified against the signature, so we effectively > verify that the artifact is associated with upstream repository.
>> I still don't get what attack in its current form it is actually >> supposed to prevent. > > My understand would be PyPI itself or CDN being compromised -- i.e. > a third party adding/replacing a sdist (in our case) that did not > originate from upstream repository. CDN compromise is protected by a) TLS, b) geographically global verification of Manifest. So is PyPI compromise after the fact. PyPI compromise of any sort will be all kinds of headline news, and will affect far more packages not covered by this snake oil at all, even for updating ebuilds. So we are left with "someone hacks pypi's underlying server, affecting only packages released after that date". The fact remains that for packages which enable github actions based automation of release (mandatory prerequisite for "provenance"), no non-github publishing tokens traditionally exist, and it is astronomically more likely -- in fact, very likely, actually -- that compromised packages will be compromised via a hacked password or a leaked github token, or via supply chain security attacks. In all plausible cases, the malicious artifact has originated from the upstream repository and the provenance check passes. I already pointed all this out. This sort of thing *already* happens practically on the regular. As you already pointed out, it is security theater. Therefore I don't see why we should take any risk at all in the possibility of the people who already replied to this thread saying they'd impute meaning to this flag, actually doing so. Meanwhile, the fact that provenance exists at all has measurably decreased the security of software I care about, since provenance was used as an excuse to disable the ability of members of the PGP community to upload code-signing attestations, and consequently, authors of software I package and use have said "it's not worth fighting PyPI, no I won't upload to github releases, blame PyPI. I'll just only continue signing my non-PyPI software projects". I think it sends an extremely bad message to approve and condone something that will always pass provenance checks **even if it is malicious**, and frankly I'm not sure why despite *you* saying it's security theater, you're determined to add it anyway. -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
