Repo-quarantine – run untrusted repos in a disposable VirtualBox VM

@pigfox

Published: Jun 18, 2026

Updated: Jun 28, 2026

I kept hitting the same problem: someone sends a repo and says "clone this and run it."

A hiring challenge. An unvetted dependency. A "just try this and tell me what you think."

The catch is that running unfamiliar code is genuinely risky — and not in an abstract way. The install step alone (npm install, composer install) can execute arbitrary code before you've read a single line. There's a known social-engineering pattern that weaponizes exactly this against engineers and job-seekers.

So I built a small workflow to do it safely-ish, and I want to be precise about that "ish."

repo-quarantine is two scripts and a README:

→ Harden a disposable VirtualBox VM (escape channels off, non-privileged user, snapshot baseline)

→ One command: boot clean → drop into the VM → do your poking → exit → roll back, wiping everything the code did

The honest scope, which I lead with in the README: it isolates your host filesystem via disposable rollback. That's the guarantee. It does NOT isolate the network, so nothing real — keys, credentials, wallets — ever goes in the VM. I'd rather ship a tool with clearly-stated limits than one that overpromises "safety" and quietly leaves a gap.

That framing discipline mattered more than the code. The first version was literally called "safely-run-repo," and the most useful thing I did was admit that name was a promise I couldn't keep, and rebuild the threat model around what's actually true.

Built under Pigfox LLC. It's a workflow I use, not a battle-tested product — feedback welcome, especially on the network-exposure tradeoff.

GitHub - pigfox/repo-quarantine: Safely run an unknown repo on local machine · GitHub

#engineering #security #golang #opensource

Like 4 Replies 6

Replies

Welcome, guest

Join ArtofBlockchain to reply, ask questions, and participate in conversations.

ArtofBlockchain powered by Jatra Community Platform

Shubhada Pande

@ShubhadaJP • Jun 18, 2026

This made me think about the hiring side more than the tool side.

When a Web3 company gives a take-home task, maybe the instruction should not stop at “clone this repo and run it.” They should also say whether testnet-only setup is enough, whether any real keys are needed, and what candidates should avoid putting into .env.

For candidates, this is also a hiring signal. How to handle an unknown GitHub repo during a blockchain developer take-home assignment without exposing wallet keys, RPC credentials, API tokens, or local system access is probably part of professional judgment now.

Would be interesting to know how senior devs here explain this boundary to juniors without making them afraid of every repo.

2

amanda smith

@DecentralizedDev • Jun 18, 2026

One practical angle here: candidates also need language for this.

If a company sends a repo and says “run it,” a junior developer may not know whether it is okay to ask questions before running it. But a simple reply like “I’ll run this in a clean test environment with throwaway credentials and no real wallet/API keys” should sound professional, not suspicious.

Maybe this is now part of how blockchain developer candidates should handle unknown GitHub repos in Web3 take-home assignments without exposing private keys, wallet files, RPC credentials, API tokens, or local machine access.

Would senior devs here see that as a good signal, or would it feel like the candidate is overcomplicating the assignment?

1
ChainMentorNaina

@ChainMentorNaina • Jun 20, 2026

@pigfox , one thing I’m curious about from the hiring-task angle.

If a junior Web3 developer receives an unknown repo as a take-home assignment, what would you personally consider the minimum safe setup before running it?

For example, is a disposable VM enough for most cases, or would you still recommend throwaway wallets, testnet-only accounts, no real .env values, and maybe no personal GitHub/SSH/API tokens inside that setup?

I’m asking because many candidates may not know where “reasonable caution” ends and “overthinking the assignment” begins.

2

Peter Sjolin

@pigfox • Jun 20, 2026

@ChainMentorNaina I would recommend using only disposable items in the VM. Create a separate wallet with little or no value in it. An unknown repo should be considered infected until proven otherwise. I would also favor procedural thinking, following a safety process every time.

2

SmartContractGuru

@SmartContractGuru • Jun 28, 2026

This is exactly where I think juniors get confused.

A disposable VM reduces host-machine risk, but in a Web3 take-home repo the bigger mistake may be bringing real things into the “safe” setup — main wallet, old .env file, personal GitHub token, SSH key, paid RPC endpoint, exchange API key, or even a browser profile that is already logged in somewhere.

For me, the minimum setup should probably be:

clean VM, throwaway wallet, testnet-only funds, fresh .env, no real API tokens, no personal SSH keys, no reused RPC credentials, and no important files mounted from the host machine.

One question for @pigfox and others here: when a candidate receives an unknown blockchain repo as a hiring assignment, what is the most reasonable safety checklist they should follow without sounding paranoid or difficult to the hiring team?

1
Peter Sjolin

@pigfox • Jun 28, 2026

If a hiring team is actually real and professional then they will be aware of the dangers that come with unknown repos and would understand the caution. If a stranger says "just trust me", you probably shouldn't.

1