You pushed hue_palette 1.0.0 to rubygems.org and it contains an API token by mistake. What does gem yank do, what does it not undo, and what do you do next?

## What yank is for `gem yank` removes a version you pushed from the **index** of the push server. After that, `gem install hue_palette` and version resolution no longer find it, and the version stops being offered as a candidate for new installs. RubyGems' help text calls it the command that "permanently removes a gem you pushed to a server." Typical reasons to yank: - the release contains a secret or private file; - the release is badly broken, for example it cannot be loaded at all; - the release was pushed by mistake or under the wrong name. A merely buggy release usually gets a fixed follow-up version rather than a yank, because users who locked that version may need to reinstall it. ## Running it ``` gem yank hue_palette -v 1.0.0 --otp 123456 ``` - `-v VERSION` is **required**; without it `gem yank` prints `A version argument is required` and stops. - `--platform PLATFORM` yanks only one platform-specific build, such as a precompiled native gem. - The API key needs the **`yank_rubygem`** scope; a key created with the default `index_rubygems` and `push_rubygem` scopes lacks it, and `gem` offers to add it. - With MFA enabled, a one-time code is needed, via `--otp` or `GEM_HOST_OTP_CODE`. - `--host` targets another gemcutter-compatible server, such as a private one. ## What yank cannot undo Yanking changes what the index offers from now on. It does not reach anything that already happened: - **Downloads that already happened.** The `gem yank` help warns that once a gem is pushed, "several downloads will happen automatically via the webhooks"; mirrors, caches and anyone who installed in the meantime keep their copy. - **Installed copies** on users' machines and build caches stay installed. - **The version number's history.** Copies of `1.0.0` exist, so publishing different contents under the same number would leave two files claiming to be one release; the fix goes out as a new version. This is why the help text puts the secret first: "If you accidentally pushed passwords or other sensitive data you will need to change them immediately and yank your gem." ## The response, in order 1. **Revoke or rotate the leaked token** at its issuer. Treat it as public from the moment of the push; yanking does not make it secret again. 2. **Yank** `1.0.0` so no new installs fetch it. 3. **Find how it got in.** Usually `spec.files` is too broad: a recursive `Dir` glob over the whole project, or a git-tracked config file that should never be tracked. Tighten `files` and check the result with `gem spec hue_palette-1.0.1.gem files` or `gem unpack`. 4. **Publish `1.0.1`** with the fix. 5. **Tell users** in the changelog or release notes, so anyone who installed `1.0.0` upgrades. ## Who can yank - Only **owners** of the gem can yank it, and each needs an API key with the `yank_rubygem` scope. - The key decides, not the machine: `GEM_HOST_API_KEY` or `--key NAME` selects which stored key is used. - A private gem server that speaks the same API takes the same command with `--host`. ## Yank versus alternatives | Situation | Better tool | |---|---| | Secret or private file shipped | rotate the secret, yank, push a fixed version | | Broken release that cannot load | yank, push a fixed version | | Bug with a workaround | push a fixed version and leave the old one | | A release you want users to test first | a prerelease such as `1.0.0.rc1` | ## Preventing a repeat - Build `files` from an explicit list or `git ls-files`, never from a recursive glob of the whole directory. - Keep secrets out of the repository entirely, so no file list can pick them up. - Inspect every `.gem` with `gem spec ... files` before `gem push`.