skip to content

After a committed credential is rewritten out of a repository's history, which copies of that value can still exist?

level: middleimportance: must knowfreq 58%

answer

  1. a rewrite has a radius
  2. copies taken before you acted
  3. forks and mirrors are separate repositories
  4. backups restore what you removed
  5. one copy nothing reaches

basics

~20 s

A history rewrite reaches only the repository you rewrote. Clones, forks, mirrors, the hosting platform's cached view, build logs, published artefacts and every backup taken in those six weeks still hold the value - as does anyone who read it.

solid answer

~50 s

Rewriting reaches one repository. Everything that took a copy before you acted keeps it: clones on laptops and build machines, forks and mirrors in other accounts, the platform's cached view of a revision no branch reaches any more, build logs and published artefacts that embedded the value, and backups - assume one archive a night and six weeks gives you about 42 restorable snapshots containing it. Each of those has a different owner and a different cost to clean: your own history is cheap, fork owners may be unreachable, and you will not delete a backup set to remove one value, so retention is what ends that copy. One copy no cleanup reaches at all: whoever already read the value. That is why replacing the credential is the only remedy that covers every copy at once.

code

json · 13 lines
json
{
  "exposedValue": "partner-integration-credential",
  "committedFor": "6 weeks",
  "copies": [
    { "copy": "earlier revision in this repository", "reachedByHistoryRewrite": true,  "endedBy": "the rewrite" },
    { "copy": "clones on laptops and build machines", "reachedByHistoryRewrite": false, "endedBy": "each holder re-copies" },
    { "copy": "forks and mirrors in other accounts",  "reachedByHistoryRewrite": false, "endedBy": "each owner, if reachable" },
    { "copy": "platform cache of an unreachable revision", "reachedByHistoryRewrite": false, "endedBy": "platform-side request" },
    { "copy": "build logs and published artefacts",  "reachedByHistoryRewrite": false, "endedBy": "purge and republish" },
    { "copy": "42 nightly archives (one per night)",  "reachedByHistoryRewrite": false, "endedBy": "retention expiry" },
    { "copy": "whoever already read it",             "reachedByHistoryRewrite": false, "endedBy": "replacing the value" }
  ]
}

go deeper

for a junior

Learn the list itself: clones, forks, mirrors, platform caches, build outputs, backups, and people. A rewrite touches the first repository only.

for a middle

Explain why each copy survives - a clone is a full copy taken at a moment in time, a fork is a separate repository, a backup exists to restore a past state.

for a senior

Rank the copies by who owns them and what each costs to clean, and use that ranking to argue for replacing the value before starting the cleanup at all.

for a principal

Note what the table implies about credential design: short-lived per-consumer credentials turn this whole exercise into waiting for an expiry, which is the structural fix.

## What a rewrite actually reaches Rewriting history replaces the revisions in **the repository you ran it against**. Anything that took a copy before that moment is unaffected, because a copy is a separate artefact with a separate owner. This is the whole reason the question is asked: candidates model the repository as one authoritative object with one current state, when it is a source that has been fanning out copies continuously for six weeks. ## The copies, and who owns each one | Copy | Why a rewrite misses it | What ends it | |---|---|---| | Earlier revision in this repository | Nothing - this is the one it reaches | The rewrite | | Clones on laptops and build machines | Each is a full copy taken at a point in time | Each holder re-copies or discards their own | | Forks and mirrors in other accounts | They were copied out; a rewrite does not propagate to them | Their owners, if you can reach them all | | The platform's cached view of an unreachable revision | Hosting platforms often keep a revision servable by reference for a period after nothing points at it | A platform-side request; how long it lingers differs by platform | | Build logs and published artefacts | A build read the file and wrote the value into its output | Purging outputs and republishing | | Backups and archives | The snapshot predates the cleanup and is restorable by design | Retention expiry - you will not delete a backup set over one value | | Whoever already read it | It is not a system you control | Nothing. Only replacing the value makes it worthless | ## The ranking that matters in practice - **Cheapest:** your own repository. One operation, one owner, done in minutes. - **Moderate:** clones and build outputs. Slow but tractable - you can list the machines and the pipelines, and you can tell their owners what to do. - **Expensive:** forks and mirrors. Copies you do not own, sometimes in accounts you cannot see, held by people who may no longer be around. - **Not really cleanable:** backups. They exist precisely so that a past state can be recovered, and deleting a retention set to remove one value costs you the recovery property you bought it for. You wait out retention. - **Uncleanable:** a copy already in someone's hands. Nothing you do to any system reaches it. ## Why that last row decides the strategy The list is long, most of it is other people's work, and the bottom row cannot be finished at all. So the remedy that covers every row simultaneously is the one that makes the value itself worthless: **replace it, and withdraw the old one**. After withdrawal every copy in the table is a string of characters that no longer opens anything, and the cleanup becomes ordinary hygiene rather than incident work. Running the table top to bottom before withdrawing means spending days on partial coverage while the value stays live. A related trap: teams count their progress in copies removed. That number moves steadily while the exposure does not move at all, which makes the work feel successful. The number that reflects the exposure is binary - does the old value still authenticate. ## What this implies about how you commit 1. **Treat committed as taken.** Once a value has been in a repository for any meaningful period, the copy set is not enumerable, so the only safe assumption is that it left. 2. **Budget for the copy fan-out when you choose credentials.** A short-lived, per-consumer credential turns this table into an expiry; a long-lived shared one turns it into a coordination exercise across every consumer. 3. **Expect the history rewrite to be the easy part.** The hard part is the set of copies you do not own, and it grows with the age of the exposure. Six weeks is a fundamentally different clean-up from six minutes, even though the deleting commit looks identical. One honest caveat about the platform cache row: whether an unreachable revision stays fetchable, and for how long, is a design decision that differs between hosting platforms. Do not assert one behaviour as universal. Assert the shape - a revision nothing points at may still be fetchable by reference for some period - and find out which behaviour your platform has before you claim that copy is gone.

  • Which of these copies is cheapest to end, and which is most expensive?
    Cheapest is the repository you own - one operation, one owner. Most expensive are forks and mirrors, because each has an owner you must find and persuade, and some are in accounts you cannot see. Backups sit outside that ranking: you wait for retention rather than deleting them.
  • Every clone holder re-copies and every artefact is purged. What still carries the value?
    The archived snapshots until their retention expires, any fork or mirror you never found, whatever the hosting platform still serves by reference, and every party that already read it. That residue is why replacement rather than cleanup is the remedy that actually closes the set.
  • Why is counting removed copies a poor progress measure during this work?
    Because the count rises steadily while the exposure is unchanged - the value is equally usable after nine copies are cleaned as after one. The measure that reflects the exposure is whether the old value still authenticates, which is binary and checkable.

saying these in an interview costs you the question

  • Believes a history rewrite propagates to clones and forks
  • Thinks backups are cleaned by the same operation
  • Treats a fork as a view of the original rather than a separate copy
  • Assumes build outputs are discarded automatically
  • Counts future clones as the exposure while the live value is untouched
  • Asserts one platform's caching behaviour as universal