The 2026-09-12 CT 101 502 incident fix (api-watchdog: detects the API
container hanging while docker still reports it healthy, and restarts it)
only ever landed in argus-appliance's docker/docker-compose.yml, the
source-build dev compose. It never reached this repo, which is what
update.sh/install.sh on every real Docker-based install actually use --
so the mitigation never shipped to a real install. Ported the service
(built locally from a bundled Dockerfile, since there is no released,
cosign-verified argus-api-watchdog image yet) plus its build context.
Companion to argus-appliance issue #88. update.sh no longer trusts the
version manifest alone -- before pulling or restarting any service, it
independently resolves each image's live registry digest and verifies it
matches what the release pipeline recorded, then cosign-verifies the
signature against the committed public key. Aborts (installation
untouched) on any mismatch, missing tool, or ambiguity.
:latest is three independently-mutable registry tags with no cross-image
transaction -- update.sh pulling it directly could observe a torn set
mid-promotion (api already retagged, ui/proxy not yet). latest-version.json
is a single, atomically-committed pointer that argus-appliance's release
pipeline only ever writes AFTER every image it names has finished
promoting, so resolving it first cannot observe a partial release: by the
time it names a version, that version is already guaranteed complete.
docker-compose.yml: image tags now ${ARGUS_VERSION:-latest} -- default
unchanged for manual/non-update.sh use (plain `docker compose pull` with
no env var set behaves exactly as before).
update.sh: resolves latest-version.json first (fails loud and untouched if
unreachable/malformed, never falls back to :latest), exports ARGUS_VERSION
for its own docker compose calls only (not written to .env), and -- new --
verifies every service's actual running image tag matches the target
version before declaring success, not just that the API container itself
reports healthy. A torn pull (network hiccup, disk full on one image) is
now a loud failure instead of a silently-reported success.
Cross-repo documentation audit against argus-appliance's real current feature set
(v3.79.80): added a Reports Center bullet (guided JSON/CSV/HTML reporting, honestly scoped —
no PDF/scheduling/compliance templates yet) and expanded the Attack Origin Visualization bullet
with the two real additions from the appliance's Attack Operations Center follow-on (attack-type
coloring, fullscreen SOC wall mode).
Moved this changelog's own "not kept in sync" disclosure from a buried trailing note to the top
of the file, right under the title, so a reader sees it before the stale entries rather than
after — same honest content, just where it's actually useful.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The service's own comment already claimed "list/inspect/exec/restart
existing containers" capability, but ALLOW_RESTARTS was never actually set
-- restart was silently unavailable. Needed for argus-appliance#43's new
Diagnostics "Restart Container" recovery action, which is the first real
caller.
Deliberately narrow, per explicit product decision: restart only (stop/
restart/kill on an *existing* container). create/prune remain denied by
the haproxy template's own explicit deny-list regardless of this or any
POST setting. start/stop (ALLOW_START/ALLOW_STOP) deliberately left unset
-- nothing needs them yet.
root