If the latter, shouldn't we have a public registry of the scanners that have run over the release, and use the registry consensus to decide when to de-quarantine a package (rather than an arbitrary time-window)?
Do you consider that if everybody does a cooldown (i.e. it is baked into the installers), they become less effective due to the fact that there is less user exposure, or do you consider that all issues are identified by code scanners?
Fully agree!
Is this a core GitHub actions infra vulnerability, or for specific actions which were using the branch name insecurely?
Find it humourous too. The "MLWP" singularity is when we can rely on them for analysing the output as well as generating it... That is when it gets super interesting IMO. For now, I think the only (huge) win is in the speed of the models vs NWP - we will still need NWP research for the foreseeable.
Sounds like there is a (security) problem with wheel unpacking if you can write outside of the cache root?
go.bsky.app/LAkKWpR
If you’re a Python person, wave frantically so I can add you to my Python starter pack!
👋 bsky.app/profile/pels...
👋 I'm a scientific Python engineer & general problem solver. I seem to have some success building open-source communities and tools, including conda-forge and SciTools (notably Iris, cartopy, cf-units), and I was previously a maintainer of matplotlib. Bringing Python to accelerator controls at CERN.
I agree. Lock files are good from a reproducibility POV, but there isn't an obvious functional improvement on a simple timestamp. I have a prototype which allows you to run a package repo server with the equivalent uv functionality for this reason (like pypi-timemachine, but in the general case)
