Guides
Unrecognised dependency sources.
Installing a Python dependency runs whatever code that server hands you, so Renest installs only from publicly known sources by default. A restore that meets any other source stops before installing anything and names the host; you allow it by naming it with --trust-host, and only if you trust whoever packed the nest.
Rebuilding an environment means installing Python dependencies — and installing a dependency means running whatever code that server hands you, on the machine you just rented. So Renest only installs from sources that are publicly known and accountable.
Everything else is refused by default, with a way out. This page is that way out.
Known sources are the public package indexes, code hosts and mainstream mirrors
PyPI, the official PyTorch index, GitHub / GitLab, NVIDIA — plus the mainstream Chinese mirrors (Tsinghua TUNA, BFSU, Aliyun, Tencent Cloud, Huawei Cloud, Baidu, NetEase, USTC, Peking, Nanjing, SJTU, Zhejiang, HIT and others), because a large share of real setups install through them.
The full list ships with the tool as a data file, separate from the tool's own version.
Renest offers to refresh it once, and renest update-rules does it whenever you ask —
going online is always something you agreed to. If we're missing a source that ought to be
there, the last section below gets it added for everyone.
Being on this list does not mean a package is safe: anyone can publish to any of these hosts. What the list stops is a nest quietly pointing your machine at a server nobody has ever heard of.
This check covers dependency installs only. Your model files travel a different path (downloaded by Renest itself and verified byte for byte); they are not affected.
You get told twice — the first time is the one that matters
1. When you pack: a heads-up, not a block
renest pack never refuses to pack. If your lockfile points at something we don't
recognise, the pack still completes and the report carries a line telling you that these
sources exist and that a future restore will stop on them.
That warning arrives while the original machine is still alive. That is the whole point of showing it there. Deal with it while you still can and no future restore will ever surprise you.
2. When you restore: a stop, with the sources named
If you skipped the heads-up, the restore halts at the dependency step. Nothing is installed — it stops before running anything, not halfway through. The message names the sources that triggered it.
First answer one question: did you pack this nest, or did someone hand it to you?
Everything turns on that. Allowing a source means letting that server's code run on your machine, where it can read the models you just restored, your storage credentials, and whatever else lives on that pod.
You packed it yourself — name the host and re-run
Say which host you're allowing. Naming it is the point: you have to type the domain, so you see what you're trusting instead of waving through something you never read.
renest restore --grant <code> --dir /workspace --trust-host nexus.mycorp.com
Repeat --trust-host for more than one. The escape-hatch script names hosts through an
environment variable, same effect:
RENEST_TRUSTED_HOSTS=nexus.mycorp.com GRANT=<code> TARGET=/workspace bash restore.sh
Once per machine. If your team maintains a base image, bake the hostname into it and machines built from it never ask again. For rented machines you throw away afterwards, don't bother with the variable — naming the host on the command line is faster.
Someone handed it to you — stop
Look at the domain in the message. Do you recognise it?
- No — don't allow it. Go ask the person who sent you the nest why their environment installs from that domain. A nest built to attack you can use exactly this step to ship your files somewhere else, and the restore will look completely normal while it happens.
- Yes, and you trust the person who sent it — allow it as above.
What we can do is stop and put the domain in front of you. The judgement we cannot make for you is the only one that matters: do you trust whoever handed you this nest?
This cuts both ways: if your own setup uses an unusual source, everyone you hand the nest to will hit the same stop. The warning you get at pack time says so.
It's a well-known public source and we got it wrong
Open a support ticket from your Renest account and include the hostname. (renest support
turns the failed run into text you can read first and paste in; it never uploads anything
by itself.) The list is not hardcoded in the tool: we publish an updated one, and every
client picks it up the next time it refreshes. You don't upgrade anything.
There is no "allow this? [Y/n]" prompt, on purpose
Plenty of people bring machines up from scripts, in batches. A prompt waiting for a keystroke doesn't protect them — it hangs the whole run, which is worse than an error that at least tells you what to do. And faced with a URL they can't evaluate, someone in a hurry to get an image out will press Y every time; asking would be theatre.
So: refuse by default, and make the way through obvious.
It blocks unfamiliar servers; it doesn't make trusted ones safe
It blocks a nest that points your machine at an unfamiliar server. It does not make trusted sources safe — anyone can publish to GitHub. The real question is the one no software can answer for you: do you trust the person who handed you this nest?
Renest asks you to confirm that before you restore someone else's work. This check is the floor underneath that decision, not a replacement for it.
One thing the error message will never do is teach you a shortcut past itself. There is a
blanket switch, --trust-unsafe-urls, and it exists for one narrow case: automation
running over nests you packed yourself, in batches, where naming hosts one at a time is
not workable. It is ignored outright for a nest someone handed you — there, naming the
host and naming the sender are both required, by hand. And we do not print it in the error
text, because an error message that hands you the bypass is an error message written for
the attacker.
These docs describe renest 0.1.15, the latest release.