Skip to main content
Revocation is the response when a signing key, a published archive or a plugin release turns out to be unsafe. The agent enforces a local revocation list: plugins signed by a revoked key, installed from a revoked archive, or at a revoked version are stopped and disabled, and cannot be installed or enabled again. Files are not deleted.

​
The revocation list

The installer writes an empty list when the file is absent and never overwrites an existing one:
  • signers holds revoked signer ids. It covers every plugin signed by that key.
  • archives holds lowercase sha256 hex digests of .adosplug files. It covers one exact archive.
  • versions holds <plugin_id>@<version> entries, for example com.example.my-plugin@1.0.3. It covers one release of one plugin, whatever archive it came from. The key is optional.
A bare JSON array of signer ids (["example-2025-X"]) is also accepted, and so is the registry’s own shape (signer_keys, plugin_versions, generated_at). An entry in versions that is not <plugin_id>@<version> makes the file unreadable. A file that exists but cannot be read or parsed is treated as fail-closed: signed plugins are refused install and enable with revocation_list_unreadable until it reads, and the plugin host keeps enforcing the last good list.

​
Where entries come from

  • You. Edit the file directly or distribute it through your own configuration management.
  • The registry. About a minute after start and then once a day, the agent fetches the registry’s /v1/revoked.json (see Catalog and registry) and merges it into the local list: signer_keys into signers, plugin_versions into versions. The merge is add-only: it never removes an entry you or an earlier fetch added. A failed fetch is logged and retried at the next cycle.

​
What happens when the list changes

The plugin host checks the file every 5 seconds and at start. No restart is needed. Within about 5 seconds of a change:
A revocation disables plugins as soon as the vehicle is disarmed. Plan a replacement before you revoke a key that a fleet depends on in flight. See Safety.
Your options for a disabled plugin:

​
Issuing a revocation

When a key is compromised or a publisher leaves your trust set:
  1. Add the signer id, the archive digest or the <plugin_id>@<version> release to /etc/ados/plugin-revocations.json on every agent.
  2. Generate a fresh key, enrol its public key, and re-sign your current releases (see Signing keys).
  3. Tell operators which plugins are affected and which releases replace them.
The registry also records signer-key and plugin-version revocations, hides a revoked version from the catalog, and publishes the list at /v1/revoked.json.

​
Operator checklist

  1. Read the reason. A safety reason means ground the affected vehicles first.
  2. Run ados plugin list on every node to find affected plugins.
  3. Install the replacement release.
  4. ados plugin remove <id> for the revoked install.
  5. Confirm the refusal and removal in journalctl -u ados-plugin-host.

​
Reporting a security issue

This page is the one home for security reporting across the agent, Mission Control and extensions. If you believe a plugin or an ADOS component is malicious, broken in a way that affects flight safety, or leaking data, report it privately: use the contact channel on altnautica.com and mark the message as a security report. Do not open a public issue. Include:
  1. The plugin id and version, or the component and version.
  2. The signer id (from ados plugin info <id> or the archive’s SIGNATURE file).
  3. What happens, with reproduction steps where possible.
  4. The operator-facing impact (data loss, vehicle behavior, information disclosure).
  5. Whether you have already disclosed publicly, with a link if so.
  6. Logs, captures or analysis output that support the report.
  7. How you would like to be credited, if at all.
We acknowledge and triage, investigate, revoke the affected signer or archive and ship a fix, then coordinate disclosure with you and publish what changed. We default to coordinated disclosure and ask for a heads-up if you disclose on your own timeline. Plugin authors should give their own users the same: a private reporting channel stated in the plugin’s README.

​
Next steps

Signing keys

Generate and enrol a replacement key.

Legal and licensing

Licences and distribution channels.
Last modified on October 11, 2026