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

Juan Nunez-Iglesias 1d ago

@brettcannon Amazing, thank you! Indeed thank you to all the PyPA folks who implemented trusted publishing, thanks to whom napari automagically ticked box 2 after ticking box 1:

https://pypi.org/project/napari/0.7.0/#napari-0.7.0-py3-none-any.whl

and thank you very much for the blog post which made it easy for go check that!

We still use requirements.txt files for our CI constraints, though, so we'll look into migrating to pylock.toml!

Client Challenge

Show thread

Juan Nunez-Iglesias

@brettcannon One thing I'm not clear on: we don't use lock files for "library" use, ie if you pip install napari, you get whatever new version of the dependencies is up there. So this wouldn't help in that scenario, right? Is your assertion that it would have helped people catch on faster, or that we should all be locking our dependencies? (Which I think is generally an antipattern in Python as it leads to mutually incompatible libraries...?)

Show thread

Almar 23h ago

@jni @brettcannon That's what I thought as well. I guess the final responsibility if for the end user to make sure their packages are sound, and a lockfile would help there.

Though perhaps we library maintainers can play a role by using a lockfile only for CI, and update it regularly to spot upstream compromised packages? Preferably in an automated way?