Mastodawn

RE: https://fosstodon.org/@jni/116287554201659198

I said digital attestations and `pylock.toml` would have helped with the litellm attack. People asked for more details, so I wrote a blog post explaining why. It also hopefully acts at motivation for people to use:

- Trusted publishing
- Digital attestations
- Lock files, and `pylock.toml` specifically

https://snarky.ca/why-pylock-toml-includes-digital-attestations/

So yes, @jni , I have a "human-readable intro" because I wrote one for you (and the other folks asking me questions on the subject). 😁

Show thread

Ryan Hiebert

@brettcannon this seems like it really puts new platforms at a disadvantage if security only comes from having enough money to convince pypi that you’re good enough to be a trusted publisher. If codeberg can’t get it even though many people are using it, that really makes it difficult.

Show thread

Ryan Hiebert 1d ago

@brettcannon I get that we wouldn’t want bad actors as trusted publishers, but I do wonder if we’re being too careful on allowing new trusted publishers, since we do require the trusted publisher to be authorized by the specific project, inherently limiting the damage. Re-upping the recent thread on the discussion board, it seems like there is at least some sentiment in that direction.

Show thread

Carlton Gibson 1d ago

@ryanhiebert @brettcannon yes… 🤔 I’m really happy to jump through any kind of local signing flow, such that “yep, that was definitely me” but delegating releases to the oligopoly is not progress. Alas.

Show thread

Seth Larson 18h ago

@ryanhiebert @brettcannon yeah, we need to figure out how we can provide some link to tie an archive on PyPI back to a claimed source code reference (whether that's git or a URL). Especially now that many folks are self-hosting their infrastructure.

What comes to my mind is focusing on build reproducibility, submitting a "claim" within a package (source code ref, build backend version, tool versions, etc) and having that claim verified by another party.