Security and supported scope

Debuglet v0.2.0 is an alpha for trusted Linux amd64 environments. It is suitable for controlled evaluation and development. It is not a general-purpose sandbox or a production payment system. The limits below describe that published release. For a newer source build, use the repository documentation and compatibility reference from that revision; source features may not be released.

What operators can rely on

• A managed dispatcher authenticates protected API requests and authorizes users to their own data.
• Executors identify their control session to the dispatcher and require both control paths to be live.
• Networked deployments can use TLS and executor client certificates.
• The dispatcher stores results and logs so clients can read completed measurements after a restart.
• The operator controls which destinations an executor permits.

Important limits

• A debuglet is not strongly isolated from the executor process. It has no host filesystem or ordinary sockets, but it runs without a general CPU, memory, or namespace sandbox.
• The destination policy is an operator control, not evidence that a destination consented to being measured.
• Interrupted measurements are not resumed, and cancellation does not prove remote termination.
• TEST payment bookkeeping moves no money. Blockchain payments are outside the supported profile.
• Account registration and login attempts are not rate-limited. Limit network exposure and use an identity provider or network controls appropriate to your environment.
• Checksums help detect a changed release file. They are not release signatures.

Operate safely

Keep private keys, account credentials, executor databases, and dispatcher databases readable only by the relevant service account. Restrict API and SSH access, keep a database backup before upgrades, deploy one reviewed release version across the service, and submit a small measurement after every deployment.

The repository's security policy explains private vulnerability reporting. Report suspected vulnerabilities privately; do not include technical details, credentials, or exploit material in public issues.

Abuse reports and destination opt-outs

Report suspected executor traffic through the deployment operator's established contact. If no private contact is available, open a project issue requesting a contact without attaching packet captures, credentials or personal data. Share the destination, time window and affected version privately with the operator. A project issue does not itself apply a destination block.

The dispatcher operator should inspect the reported runs and choose the smallest safe response. An authenticated operator may set a destination bandwidth limit with PATCH /destination and {"destination":"ADDR","limit":0}; the API contract defines the request. Check its actual response: 204 records the limit and confirms that each executor holding an allocation received the updated share; 409 means the requested limit is below admitted floors and nothing changed; an error that says delivery is incomplete means the recorded admission limit has not reached every executor. Coordinate active work with its owners, retry after allocations are released where needed, and inspect delivery failures before reporting success.

Dispatcher limits match the declared destination string, not a resolved prefix, and are held in memory. Reapply them after restart. A zero limit is not a durable opt-out and does not establish that every current packet has stopped. An executor operator can add an address or CIDR prefix to denied_destinations in [network.policy] and restart that executor to apply it. Editing a configuration file alone does not change a running executor's policy. Keep any interruption and retained results visible to affected users.

Record the report, destination, response time and observed outcome in the deployment's records; tell the reporter about any refused or incomplete action. Do not claim destination consent, remote termination or successful blocking from a run ID, packet tag, cancellation acknowledgement or limit response alone. This procedure is documented but has not been rehearsed as an abuse-response exercise.

The published v0.2.0 threat model describes that release's identifier and enforcement limits. Use the versioned references from the selected source when evaluating a newer build.