Allow a reverse-publication flow

[tadasant]

For the purpose of quickly deleting accidentally-published data.

I think we could probably just allow this functionality indefinitely? But I know some registries have a limit (e.g. RubyGems only allows this for 30 days); curious to review why that is.

If we do introduce a limit, we'll probably need another mechanism for facilitating deletions outside that window (e.g. in the case someone published private data and didn't notice for a while).

[sridharavinash]

There are some useful guidances that maybe useful for us to consider https://repos.openssf.org/package-deletion-policies

[joelverhagen]

On NuGet.org we take a relatively cautious approach and generally recommend authors publish a newer version instead of trying to remove the old version. However, we do support automated deletion when the package meets these criteria:

• less than 125K cumulative downloads on all versions (highly popular packages can't delete at all since consumption after publish is very fast)
• less than 150 downloads for that specific version
• published within the last 24 hours

Any time you have deletion you need to decide whether a subsequent publish with the same version is possible (effectively allowing mutability). Our OpenSSF doc suggests immutability (blocking the package version if it was deleted, so the new publication much have a different -- generally higher -- version).

[domdomegg]

I think we might be able to go live with basically no reverse-publication flow, except for a exceptional case manual override flow.

Reasoning:

• There is a bare minimum where we probably have to delete entries: where they have malicious, abusive, illegal, dangerous or copyrighted content. We also probably want to delete spam entries. In most other cases I think we should encourage people to simply publish new versions.
  • In most of these cases, the package owner has likely intentionally put spam/malicious content there - so offering them a flow to delete won't help.
  • I think as a result cases where it is accidental and the package owner wants to unpublish will be very rare. Cases I can think of (which I think will be rare) are:
    • Where a publisher's credentials get hacked/leaked, and someone publishes spam/malicious content in their namespace that they want to take down
    • Where they accidentally embed credentials into their server.json somehow, e.g. they meant to put in an example for an API key but accidentally submitted their production API key. (Although even in this case deleting it is probably not very safe: really we want to encourage people to treat it as public and rotate the secret).
• Also precedent: other registries take a cautious approach, and prevent people deleting packages except in special circumstances. Additionally tools like GitHub also prevent people deleting content like PRs except in special circumstances, and require a manual process to go through support.

We can of course add a deletion flow if it turns out this problem happens regularly - but also we'd have learnt more about what the deletion requests are for etc. so could likely build a better flow/set of restrictions around it.

Feedback would probably be helpful on:

• do people agree or disagree with the assumptions / reasoning above, and why?
• are we good to remove the 'go-live blocker' from this issue?

[domdomegg]

For more on precedent (Claude generated, with minor edits and verification from me)

1. Maven Central (Java)

No deletion allowed: Once published, artifacts cannot be removed or edited - ever
Immutability principle: Designed to be a permanent archive to ensure build reproducibility

https://central.sonatype.org/faq/can-i-change-a-component/#question

2. nuget (.NET)

"nuget.org does not support permanent deletion of packages. [...] In exceptional situations such as copyright infringement and potentially harmful content, packages can be deleted manually by the NuGet team."

https://learn.microsoft.com/en-us/nuget/nuget-org/policies/deleting-packages

3. crates.io (Rust)

No deletion: At launch crates could be deleted by crate owners. I think they changed this in 2024 to allow deletion under very restricted scenarios, but defer to "exceptional cases crate owners may contact the crates.io team to request deletion of a crate that does not meet these conditions."

https://stackoverflow.com/questions/52639162/how-to-delete-a-published-crate-from-crates-io

[tadasant]

Interesting to see those other policies being so non-removal oriented. I think I would still be in favor of architecting something that includes removal functionality under appropriate circumstances without requiring a ping to maintainers, but the examples convince me this is not a go live blocker. Thanks for researching @domdomegg !

[domdomegg]

There's some related useful user feedback in #416

[tadasant]

Just for reference, another example: https://discord.com/channels/1358869848138059966/1369487942862504016/1417966038967914536

Though we will need to be careful with mixing immutable data vs. malleable state: https://discord.com/channels/1358869848138059966/1417915364289020045/1418253627822182574

[manusa]

Adding another example for reference:

For the Kubernetes MCP Server we're starting to work on publishing to the MCP registry in the scope of containers/kubernetes-mcp-server#555

However, one of the initial experiments during the analysis phase didn't go well, and now the registry contains a 1.0.0 version which will always take precedence regardless of whatever correct version we publish with the mask 0.y.z.

We need a way to remove that version which is invalid.

P.S. Until this is implemented, is there any other for us to request the removal of that version?