On Wed, 2025-08-27 at 14:52 +0100, Sam James wrote:
> Michał Górny <[email protected]> writes:
> 
> > On Mon, 2025-08-25 at 18:03 -0400, Eli Schwartz wrote:
> > > 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.
> > 
> > Manifests only cover what the developer has fetched.  If you believe
> > that developers actively verify the source distributions they've
> > downloaded, think again.  In fact, verify-sig was added precisely
> > because we wanted at least some minimal verification in place.
> > 
> > Please correct me if I'm wrong.  Without the change, the attack vectors
> > include all attacks against the upstream repository + attacks against
> > the PyPI infrastructure and CDN.  With the change, we're protecting
> > against the attacks on the latter, so even if you believe they to be
> > unlikely, it's still a reduction of the attack surface.  Isn't that
> > a net gain?
> 
> Right, this is the point Jay is making as well.
> 
> My issue was/is that given it seems quite weak (the lack of TOFU right
> now), it might even persuade someone that something is fine when it
> isn't if it passes, given it provides extremely little ("Oh, at least
> the provenance is fine"). On the other hand, I can't see a case where we
> *know* something is off but the provenance is fine and we therefore
> dismiss it, because of this same reason (the very weak verification).

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.

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to