A quarantine plugin is one the scanner flagged that you have not judged yet. Teams lose most of their time at this stage, because the natural first move is to open the source while the risk is still live in the background. The flagged plugin workflow below runs in the order that works: freeze the version, cut its reach, then read the script. It sets out the plugin isolation steps that run on a laptop or a shared build machine, and answers the question in the middle of all of it: how to quarantine a dsh plugin without guessing what the package can touch. A plugin quarantine is a holding state, and it ends with a decision rather than a feeling.
What flagged actually means
The scanner marks a package when its install script matches a pattern seen in risky plugins before. That is a pattern match, not a verdict. A plugin can be flagged for a postinstall hook that fetches a binary, which some ordinary tools do, and a plugin can pass the scan while behaving badly later at runtime.
| Check | What it catches | What it misses |
|---|---|---|
| Dangerous install script | postinstall hooks, curl piped to a shell | anything that runs after install |
| Missing dsh.bundle | plugins that skip packaging metadata | plugins with the field but wrong contents |
| Stale maintenance | repos that stopped shipping | an active repo with one bad release |
Treat the warning as a request to look. The mechanism behind the flag is explained at /blog/how-install-script-scanning-works.
Step 1: freeze the version
Pin the exact version before anything else. Auto-updates are why a review that started on a safe release can finish on a different one.
- Write down the version string you began reviewing.
- Pin it in the lockfile so a reinstall cannot drift.
- If it is already installed, reinstall from the lockfile instead of pulling latest.
Step 2: cut its reach
Isolation comes before reading, because reading takes an afternoon and isolation takes a minute. The plugin isolation steps below follow one rule: limit what the package can touch while you decide what it does.
- Run it in a container or a throwaway VM with no credentials in the environment.
- Point it at a scratch directory rather than your working project.
- Block outbound network when the plugin has no reason to make requests.
- Use a separate key with the narrowest scope you can tolerate, never your main one.
Isolation is cheap and you can undo it. Undoing an incident is neither.
Step 3: read the install script
Open the script instead of trusting the description. The scan tells you where to look; the rest is plain reading.
- Find anything that writes outside the plugin directory.
- Check every network call: where it goes, and whether it sends file contents.
- Watch for obfuscation, base64 blobs, or a command assembled from string fragments.
- Confirm the postinstall hook matches what the README claims the plugin does.
If the reading turns up nothing, the flag was noise and you can clear it with a note. The patterns the scanner looks for are listed at /blog/how-install-script-scanning-works.
Step 4: decide, and write it down
A quarantine ends with a decision, and the decision needs a record. Plugin problems usually surface months later, found by somebody who was not there when the call was made.
| Outcome | What to record | Next step |
|---|---|---|
| Clear it | Version reviewed, script read, who approved | Drop the pin restriction, keep it on the watchlist |
| Keep it contained | What it can reach, why that is acceptable | Leave the sandbox in place, review at the next release |
| Remove it | What triggered removal | Uninstall, purge config, note the replacement |
Three outcomes, one line each. That is short enough that people actually fill it in.
FAQ
- Is a flag the same as a bad plugin? No. A flag means the install script matched a pattern worth checking. Plenty of flagged plugins turn out fine once you read them.
- How long should a plugin stay in quarantine? Until somebody reads the install script and writes down a decision. A day is normal; three weeks means nobody owns it.
- Do I need a container? Not always. A scratch directory and a throwaway key cover most review cases, but a container is the safer default when the script touches the network.
- What if the plugin is already in production? Freeze the version first so the state stops moving, then work through the same steps. Removal waits until you have a replacement.
Every plugin page at dshquality.com shows the scan result behind its grade, so you can see which check raised a flag rather than guessing. The scanning mechanism is at /blog/how-install-script-scanning-works, the C-grade and B-grade judgement calls are at /blog/c-grade-dsh-plugins-good-enough-trap and /blog/what-a-b-grade-dsh-plugin-tells-you, and everything published on the site is at /blog.