On 8/25/25 1:35 AM, Sam James wrote: > 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.
I feel like you're entirely missing my concern. I didn't say the gain is
dubious. I said it is actively harmful.
It verifies nothing (0% usefulness, already fully covered by blake2
checksums in Manifest) while *looking* like it does something else.
Again, "security theater" is inherently damaging and detrimental to
users' and developers' understanding of threat models.
> 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.
The failure mode of this scheme is that anyone who can upload a
malicious release to PyPI can also upload a malicious provenance file
that passes validation.
***NOT*** "what if they can also".
The ability to upload a malicious release ***also grants as a side
effect*** the ability to upload a provenance file with green checkmarks.
It's the same access bit.
The whole point of "provenance files" is that you can only create them
via github actions or gitlab CI, and those are also (supposed to be) the
only thing with access permissions to publish to PyPI.
- nobody has publish tokens for PyPI, other than the forge-based CI/CD
- the ability to push commits or tags to github/gitlab by hacking
developers (ssh keys but also Personal Access Tokens) automatically
grants the ability to run CI/CD on push, because that is precisely how
the legitimate developers publish
- this whole model assumes "the cloud" is harder to hack than developer
laptops, which -- given "reusable workflows" can be and have been
hacked in the past -- is humorously the opposite to reality
- creating a release via forge-based CI/CD automatically creates a valid
"green checkmark" provenance file
In exchange for these non-promises ("participation trophy" / automatic
free green checkmarks), we get something that has to be individually
p.use.masked on a per package basis because sigstore only works on
amd64, and whose mere presence in emerge -pv output causes the
maintainer of the ebuild to believe that it's "so verified already that
it surely isn't worth diffing the release distfiles".
--
Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
