cli.verifier_start_failed

The verifier won't start, for want of its credential or a sandbox to run packages in, or because it can't listen.

Area 14, Tooling; not declinable; the next step is usually the human's.

Why Jadpo refuses it

The verifier runs code from anyone: a package's tests and examples, and its last release's. It runs them only in a sandbox with no network, no files of the machine it is on and limits on what they can use, and it answers only the registry, which proves itself with a credential. Without either it doesn't serve at all, since serving with less would be a way in that looks like the real thing.

So it checks both before it listens: the credential is there and long enough, and a program in the sandbox really has no network. It serves only on Linux, with bubblewrap; its container image has everything it needs.

What it looks like

Started with no credential:

jadpo package verify --serve

(human) at the end of the next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make: it decides what the verifier trusts.

How to fix it

If the credential is missing, set it to the secret the registry holds, at least 32 characters:

fly secrets set JADPO_VERIFIER_TOKEN="$(openssl rand -hex 32)"

The verifier then starts and answers only a caller that sends the same secret, so give the registry the same value.

If it has no sandbox, run it from its container image, which brings bubblewrap, prlimit and git. In a plain Docker container the sandbox needs its namespaces allowed:

docker run --security-opt seccomp=unconfined --security-opt apparmor=unconfined --security-opt systempaths=unconfined -e JADPO_VERIFIER_TOKEN -p 8080:8080 ghcr.io/jadpo-dev/verifier

It checks a program in its sandbox has no network, then listens on port 8080.

If it can't listen, give another address, or stop what holds that one:

jadpo package verify --serve --listen 127.0.0.1:8081

It then answers at that address instead.

Related

• The verifier
• jadpo package verify