A published wheel on PyPI contained an internal API token and you deleted the file — is the credential contained?

## The question behind the question An interviewer asking this wants to see whether you rank your response steps by what actually reduces risk, or by what feels like undoing the mistake. Deleting the file feels like undoing it. It is not. ## Why deletion contains nothing A public registry is a globally distributed, aggressively cached, continuously scraped surface. Between publication and deletion the artifact will have been copied into: - **public and regional mirrors**, which sync on their own schedule and may not propagate a deletion at all; - **organisational caching proxies**, which exist precisely so that upstream availability stops mattering — they hold their own bytes and do not purge because upstream removed something; - **CI and developer machine caches**, thousands of them, holding the file for as long as their eviction policy says; - **automated scrapers**, including the ones specifically watching new package publications for exactly this kind of leaked credential, which is not a hypothetical activity; - **anyone who simply downloaded it.** None of these has any obligation to notice your delete. So the correct assumption is the strict one: **a secret that was public for one minute is public forever.** ## The response order that matters 1. **Revoke and rotate the credential.** This is the only step that changes what an attacker can do. Do it before you touch the registry, because time-to-revoke is the metric that decides how much of this becomes an incident. If the token cannot be revoked without breaking something, that is an argument for fixing the dependency on it under pressure, not for delaying. 2. **Investigate use.** Assume it was used. Check the authentication and access logs of whatever the token reached, over the window from publication to revocation, and look for access from unfamiliar sources. What you find determines whether this stays an internal cleanup or becomes a customer-affecting incident with its own disclosure obligations. 3. **Scope the blast radius.** What did that credential authorise — read of an internal service, write to a registry, an ability to publish? A publishing credential is the worst case, because it converts your own leak into a mechanism for someone else to ship a malicious version under your name, and that turns a housekeeping problem into a downstream one. 4. **Clean up the publication.** Now delete or withdraw the file. It is still worth doing: it removes the easiest copy to find and stops new consumers pulling the artifact. Just do not book it as containment. 5. **Publish a clean replacement.** Under a new version number. PyPI does not allow a deleted filename to be uploaded again — the rule exists so a filename that a mirror or a lockfile recorded can never later resolve to different bytes. That immutability is a property you want; it just means "delete and re-upload the fixed file as the same version" is not an available move anywhere that takes integrity seriously. 6. **Purge your own caches.** The copy inside your organisation's caching proxy is the one you can actually do something about, and it is the one most likely to be pulled by an internal build tomorrow. 7. **Fix the cause.** The token was in the artifact because the artifact was built from a tree that contained it, or because the packaging configuration swept in a file it should not have. The durable controls are scanning the built artifact for secrets before it is published, building releases from a clean checkout rather than a developer's working tree, and being explicit about what goes into the distribution rather than relying on exclusion rules. ## Why deletion can even be counterproductive Two effects worth naming. First, deleting the file breaks any build that pinned it, so a leak in a widely adopted version turns into an availability event for consumers who had nothing to do with it — you have traded their uptime for containment you did not actually get. Second, a sudden deletion is itself a signal: it draws attention to the version and invites someone to go look at the copy their proxy still holds. Neither is a reason to leave a live secret published; both are reasons to have already revoked it before the deletion draws eyes. ## The distinction to state out loud Withdrawal controls act on **availability of the artifact**. A leaked credential is a problem of **validity of the secret**. They operate on different objects, so no amount of the first fixes the second. The same logic generalises: if the published artifact contained malicious code, withdrawal likewise does not remove it from anyone who has it, and the response is an advisory that reaches consumers plus whatever server-side revocation the code's capabilities imply. ## What a weak answer sounds like "We deleted the file and re-uploaded a fixed one, so we were fine." That answer gets two things wrong at once — the secret was never contained, and the re-upload under the same filename is not permitted precisely because identifiers must stay immutable.