1. A release turns out to contain an exploitable bug

2. A release is published to fix the bug

3. Someone malicious with access deletes the release

4. Everyone downloading the "latest" version gets the exploitable version until the developers notice and re-publish again

I think about tools used in CI systems that are often re-downloaded in each run, like `helm` or `kubectl` or `crane` for example; if they're pinning a previous version they stay exploitable, and if they're downloading the 'latest' from Github then this switcheroo keeps them exploitable. Given that a lot of emergency security releases come with disclosure ("this is being released to resolve CVE-2025-12345") another 12 hours of exploitability can be critical.

Thanks, interesting scenario, but if you have access to releases like that how is this easier vs just publishing a release with an exploit and getting the same X hours before you're discovered?

Deletion creates a hole. The hole can be filled by something else. This is a form of mutation.

What you probably want instead is one-way revocation. You place a permanent marker that says "do not use this release because it is {broken, malicious, ...}".

No, you can make the whole immutable, that is if a tag in an immutable repo was used and deleted, it can't be used again

An "immutable hole" just sounds like a "revocation marker" without an accompanying message, so I don't think we're really asking for different things, here. Nevertheless, ordinary tag deletion -- what git natively supports -- can't be supported directly.

The difference is the unavailability of content. For example, you attach the wrong binary and want to avoid confusion/mistaken downloads either manual or via tools that don't support your markers, in the most direct way - by deleting the binary from release. But you can't fix it if you opted into the security benefits of no hidden mutation

I think the reason here is to prevent deletion that cause upstream disruptions.

See the reasoning in the PEP 763 (not adopted )

https://peps.python.org/pep-0763/

Strange they haven't identified negative security implications: if the owner notices the hack he can delete the malicious release before the central authority, so this would limit the blast radius (think there was a recent such issue with npm where there was a delay between discovery (by the author) and removal)

Otherwise yes, leftpad/coverup risk is a thing

I'd guess one MO is to delete a malicious package/url shortly after releasing it to prevent researchers from getting to it.

So they wouldn't make a release immutable?

Which means the tainted release doesn't matter anymore to those consumers worried about the immutable release attestation anyways. If others are worried about that, they should probably consume only attested immutable releases as well.

I'd still bet the larger portion was it was just a particularly easy path to preventing downgrade attacks or the like though. Could always be more to it as well I'm not thinking of, just feels likely.

I assume they're doing the trivial workaround to prevent renaming by way of delete and recreate?

Then you'd ban the recreation part?