I agree but think the problem is slightly more general. Consider that a package could be redacted not just due to exploit but also (among other things) for legal reasons, and that such reasons could be region specific. So a redacted package might or might not be available to manually download and some other metadata is desirable so that "audit" can notify you that you were compromised.
A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence!
I would suggest that such packages should simply require authenticated access + manual “write an email to ask to have your account be put on a whitelist”-driven authorization. Such a package would still be there (in its redacted state); but attempts to download it would be a 401 (if unauthenticated) or 403 (if not on the whitelist) error response, which the packaging tooling would need to know how to handle.
(In any case, this “redacted” package state and my “exploited” package state could be two variants of the same logic, both following the same approach to locking/resolution, both requiring the flag to indicate that you understand what you’re doing and aren’t just going to run the resulting program. The only difference is that once you pass that flag, an “exploited” package would then just work, for anyone; while a “redacted” package would still have one more gate standing (server-side AAA) in the way.
I think maybe you're missing the significance of legally mandated redaction - continuing to provide access could well constitute a criminal offense depending on the specifics. And there may be many other reasons for redaction - as a sibling comment notes you certainly don't want to continue serving a package that contains sensitive private information.
I see the "exploit" case as a strict subset of redaction in which you do want to continue serving downloads to parties that explicitly acknowledge that they understand the classification of the artifact in question.
> A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence!
This doesn't make sense if the legal reason is accidental release of secrets or PI, in which case you absolutely do not want to leave it up.
I'm not talking about things like github tokens here, those can be revoked. But actual secrets or PI where that isn't possible.
I mean, unless the party you’re concerned about having your secret is the maintainers of the package store itself, what’s the functional difference between “it’s deleted from our servers” and “it’s marked private so only the author [or admins of the author’s org, insofar as user accounts are org-bound] can still download it”?