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.
