Yea, FWIW I’m not particularly opposed to the bypass other than as a vague-ish general push back against adding features “just in case” for a relatively small number of users and a general sense that adding features is typically easier than removing features (though it’s kind of an ironic statement since it’s in response to removing a feature ).
If folks feel like the bypass adds enough value, I wouldn’t be sad if it got added. It’s also something we could add as a follow up if we get enough people asking for it that it feels like we undercounted how important the capability was.
Thanks folks for continuing the discussion. I have pushed a pull request to Warehouse that adopts the 14 day window for publishing new files to old releases. I’ve opted to focus on protecting against attacks on compromised tokens and workflows instead of user accounts, as these are both more rare and likely to be “loud” as we don’t allow re-uploading byte-for-byte files after a release has been deleted.
I am okay with a “bypass” feature being available in the web UI, but this is its own feature that requires UI/UX work and is significantly more complicated than checking the Release.created date on uploads to achieve widespread protections for most use-cases (and prevent massive amounts of clean-up by already strained staff and volunteers fighting malware on PyPI). I think this feature can be proposed and discussed separately without blocking this protection being put in place now.
As I mentioned above, there aren’t “backwards compatibility” concerns with changing this mitigation: we can always re-evaluate or remove the protection in the future, but we can’t roll back time if its absence is abused in the meantime.
This new restriction also affects TestPyPI. I had been using it as a nightly “dry run” for end-to-end verification of the trusted publishing process. I think my only option now is to use a unique version every day instead of using “–skip-existing”, wasting space on TestPyPI. The 400 error is raised prior to the check for existing individual files: “400 Uploading new files to releases older than 14 days is not allowed.”
Yeah, I think this is going to break pretty much all of my test.pypi.org workflows. I don’t think simulating this failure case will actually be helpful, so I think disabling it for test.pypi.org is the most straightforward solution.
Another possibility would be to check if an upload is a duplicate and reject it for that reason before checking the upload window. That is already accounted for in pypa/gh-action-pypi-publish with skip-existing: true and I would guess that would take care of the majority of failures.
If resetting the clock with each upload (per Restricting "open ended" releases on PyPI? - #64 by guido) is implemented, it could be hacked around with a cron-job, assuming that duplicate upload attempts also trigger the window reset.
I’m not sure it’s a good idea to remove it from TestPyPI. The general point of TestPyPI is for it to be an accurate test environment replication of PyPI, so having subtly different release openness behaviors seems like a recipe for confusion.
Just my 0.02c, but I think this is probably fine – versions should be operationally cheap, and TestPyPI explicitly reserves the right to delete data (or wipe the entire instance) whenever the admins please
@woodruffw my main concern was for other packages that I maintain that have many wheels, like pymongo. I try not to rely on the environment to remove the files.
This is something that PyPI Admins have been discussing - and considering what it might take to remove Test PyPI completely, It was never intended to be load-bearing, it does not get much scrutiny or attention.
I highly recommend folks to figure out out deployment mechanisms without TestPyPI going forward, so that if and when an announcement arrives deprecating it, you are not surprised.
(This is not a declaration, rather a recommendation/)
I highly recommend folks to figure out out deployment mechanisms without TestPyPI going forward, so that if and when an announcement arrives deprecating it, you are not surprised.
As a lighter-weight alternative, projects I’m involved in run validate-pyproject on the packaging configs and twine check on test builds of release artifacts. It’s not perfect, but that combination catches most of the common reasons production PyPI has rejected uploads for us in years past.
other than as a vague-ish general push back against adding features “just in case” for a relatively small number of users and a general sense that adding features is typically easier than removing features (though it’s kind of an ironic statement since it’s in response to removing a feature 
).