Sam James <[email protected]> writes: > Eli Schwartz <[email protected]> writes: > >> On 8/24/25 3:12 PM, Michał Górny wrote: >>> Hi, >>> >>> Here's a patchset that introduces provenance verification (i.e. >>> verify-sig equivalent) for pypi.eclass. >> >> >> I strongly believe this should *not* be merged. >> >> There are a couple reasons why I don't think this is beneficial and >> would strongly push back against implementing it in any package I >> maintain (even if the relevant files are uploaded to PyPI). But the main >> issue is the one you said already in IRC: >> >> "yes, it worked. yes, it's all theater" >> >> I am opposed to implementing anything which even the author thinks is >> useless. >> >> I am opposed to implementing anything which constitutes "security >> theater as a matter of policy". Security theater is a *net negative*. It >> makes people think that security guarantees exist which don't in fact >> exist, and they let down their guard. > > I have to admit I'm sceptical sa > well. > https://blog.trailofbits.com/2024/11/14/attestations-a-new-generation-of-signatures-on-pypi/ > is some useful background. > > On the one hand, I feel like using something that PyPI makes available > has some weight by itself, even if we don't approve of it. > > On the other hand, the gain (at least for us, given we do source builds) > feels dubious. If I understand the mechanism correctly, it has a lot of > magic based on the GH repo and allows "automated releases" to be signed, > whereas a lot of the benefit of PGP verification is that the workflow > really steers you towards doing it manually at some point in the > process. > > Maybe more importantly: supposing verification fails for a release, I am > not sure I yet fully understand how that can happen or what it implies, > or what reasons upstream could give me that are bogus (i.e. I don't know > if having it as USE=verify-sig would achieve anything). I understand the > failure modes and weak points of PGP, I don't understand the failure > modes and weak points of this scheme yet.
>From the post I linked: > Longer term, we can do even better: doing “one off” verifications > means that the client has no recollection of which identities should > be trusted for which distributions. To address this, installation > tools need a notion of “trust on first use” for signing identities, > meaning that subsequent installations can be halted and inspected by a > user if the attesting identity changes (or the package becomes > unattested etween versions). Once this is implemented upstream (it sounds like it isn't a thing yet), combined with the fact it's the upstream recommendation (even if I don't love the scheme), I could accept it.
