# 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.

Canonical page: https://renest.ai/docs/dependency-sources

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. The same rule does apply to the recorded sources of files that don't travel in a nest someone handed you: an address on a host Renest doesn't recognise is not contacted until you name the sender with `--trust-sender`.

## 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.

```bash
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:

```bash
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.
