FRESH

Hacker News

PyPI Blog: Releases now reject new files after 14 days

61 points by miketheman

by nneonneo

0 subcomment

The remaining risk now is that a patient, malicious actor could put out a new, clean source-only release, wait for ~7 days for people to decide it's safe and update to that version (and pass typical update delay controls), and then attach a bunch of malicious binary wheels. 14 days still seems to be too long.
Of course, this is already miles better than the current state of affairs where an old but popular package could become an infection vector at any time.

by yladiz

1 subcomments

I’m a bit surprised this is possible in the first place. I get that you might not be able to upload everything in one go, but it feels like you should “start” and “finish” a release in that case, and once it’s finished you can’t modify it.
I guess the use case is that you might want to build a wheel for an older release for a newer version of Python?

by skinfaxi

1 subcomments

by kapilvt

0 subcomment

The other consideration that would be useful is an explicit api for a developer to freeze the release, to prevent new file upload.

by firesteelrain

1 subcomments

This seems like common sense configuration management 101. If I download v1.2 and it’s been published then it should be considered released and not modifiable. With exceptions for ‘dev’ releases of course. I have never published anything on PyPI but I would expect there is a publish button and finalize (?) optional button that if not checked after 14 days makes it final ?

by edelbitter

0 subcomment

> To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases
While this may quantify how disruptive the change would be to those projects that are able to and do upload additional binaries to PyPI later, it fails to quantify how many projects already completely circumvent this block before it is even introduced.
e.g. If you tell pip to install from source.. the result may already be that you install a binary that PyPI never saw. A common hack for dealing with NVidia internals, which can explode into a large CUDA major version x GPU arch x platform x implementation x python_version cartesian product. The "extras" mechanism is not quite sufficient to model such combinations.
sample code: https://github.com/Dao-AILab/causal-conv1d/blob/4f6ae4e26ae5... https://pypi.org/project/causal-conv1d/

by ascendantlogic

1 subcomments

Kinda curious why releases just aren't fully immutable? Sane semver would dictate any update should at least be a new patch release.

0 subcomment

by PhilipRoman

4 subcomments

There seems to be a severe lack of hash pinning in "modern" software ecosystems. We figured out how to do it 20+ years ago with Git bringing hash addressed storage to the masses. Coming from a different background it was very surprising for me to see things like docker images, packages and github actions being updated at the whim of upstream registry. I much prefer the philosophy where builds are fully offline and predictable, even if not fully reproducible.

by lexicality

2 subcomments

14 days still seems way too long to me. As a user I thought releases on pypi were immutable!