v0.16.1

v0.16.1

v0.16.0

v0.16.0

rustpanosmcp v0.14.0

Security

• Moved rustls from 0.23.44 to 0.23.45, closing RUSTSEC-2026-0285 (#168).
  The advisory describes a TLS 1.3 handshake vulnerability where messages could
  be accepted across encryption-level boundaries (CVSS 5.3 Medium). This
  security fix is the primary reason for the 0.14.0 release.

Fixed

• The startup refusal now prints its message, not the enum variant (#171).
  An off-loopback bind missing --allowed-origin printed Error: AllowedOriginRequired, which forced operators to read the source to
  understand the fix. The server now prints the sentence naming the flag:
  "Binding to a non-loopback address requires --allowed-origin to be set."

Changed

• --device-mapping moved into ENTRYPOINT (#166). The flag previously
  lived in the Dockerfile's CMD, which Docker replaces wholesale when an
  operator passes any override (e.g. --host 0.0.0.0). This silently dropped
  the inventory path and reverted to no device mapping. The flag now lives in
  ENTRYPOINT, which Docker appends to rather than replaces, preserving the
  inventory path across operator overrides. This changes how container
  operators pass arguments: documented docker run and compose examples
  that explicitly passed --device-mapping would now duplicate it and cause
  clap to refuse startup with "cannot be used multiple times". The updated
  docs reflect the new image contract. This closes mecmcp#357's rustpanosmcp
  case, the same defect class already fixed in rustmistmcp#78 and
  rustproxmoxmcp#85.
• Adopted the mecmcp packaging conformance check (#166), which mechanically
  gates R1 (installer is executable in git's index), R5 (uninstalled commands
  are not copied into the guest), and R6 (Dockerfile arguments cannot silently
  drop a runtime flag). The LXC installer was made executable to satisfy R1.
• Moved rmcp from 3.2.0 to 3.4.0 (#169). Upstream replaces the deprecated
  ServerInfo type with ServerConfig, which splits protocol metadata from
  server identity. No wire-format change. The ServerInfo type was deprecated
  in rmcp 3.3.0 and removed in 3.4.0; this server now uses ServerConfig.
• Moved reqwest from 0.13.4 to 0.13.5 (#165). Upstream fixes a bug in
  HTTP/2 window size handling and updates transitive dependencies. The crate
  is used for PAN-OS API requests.
• Updated the distroless/cc-debian13:nonroot base image digest (#170),
  picking up upstream security patches and glibc fixes.
• Documentation fixes: added the missing --allowed-origin flag in the LXC
  systemd drop-in example (#163), and added a complete how-to for building a
  rust-panosmcp LXC from scratch (#162).

Full changes: v0.13.1...v0.14.0

Backfilled GitHub release for an existing tag (2026-10-07).

rustpanosmcp v0.13.1

Changed

• Documented the fleet seccomp posture agreed in mecmcp#354. The systemd unit's
  SystemCallErrorNumber=EPERM directive is now documented as load-bearing:
  without it a denied syscall raises SIGSYS and kills the process mid-request,
  which is what killed rustunifimcp during a change-set state write
  (mecmcp#351). An EPERM denial is silent at the systemd layer; visibility
  requires the application to check errno instead of discarding it.

Full changes: v0.13.0...v0.13.1

Backfilled GitHub release for an existing tag (2026-10-07).

v0.13.0

Changed

• Moved rmcp from 3.1.4 to 3.2.0 (#159). Upstream adds OAuth refresh
  coordination through credential stores and request-state key rotation, and
  fixes legacy-protocol initialize, sessionless HTTP discover fallback, and
  concurrent streamable-HTTP client requests.
• Moved futures-util from 0.3.33 to 0.3.34 (#157), picking up the cloned
  waker identity fix. The crate is used in exactly one place, the size-capped
  PAN-OS response body read in rust-panosmcp-core.
• Moved docker/setup-qemu-action from 4.2.0 to 4.3.0 (#158), a
  dependency-only upstream release that carries transitive fixes including
  brace-expansion 1.1.15 -> 1.1.18. The action's own source is unchanged, and
  the release-image workflow passes it no inputs.

Upgrading

• Protocol negotiation changed for initialize. With rmcp 3.2.0, an
  initialize request naming protocol version 2026-07-28 is answered with
  2025-11-25 rather than 2026-07-28. The downgrade is unconditional --
  supplying the version in _meta does not avoid it. This is upstream's
  intent: the 2026-07-28 revision removes the handshake, so a request that both
  names that version and calls initialize is contradictory, and the server
  answers with a legacy version it supports.

  Verified against the lab rigs before release: the negotiated session is fully
  functional. tools/list returns all 15 tools and tools/call succeeds. No
  client-visible failure was observed, only a different negotiated version
  string. Clients that hard-require 2026-07-28 from the handshake would need
  to move to the stateless path.

  Requests naming legacy versions (2025-06-18, 2024-11-05) negotiate
  exactly as before, and an unrecognized version still falls back to
  2025-11-25 with HTTP 200 -- unchanged from 0.12.0.

v0.12.0

Fixed

• XML element text no longer truncated at the first entity (#151). The
  XPath set parser could silently truncate element content at the first entity
  reference, which corrupted retrieved configuration values. quick-xml's decode
  is now applied after extracting the raw text, preserving entities through to
  the final decoded output.

Changed

• Re-pinned the mecmcp-* crates from v0.21.0 to v0.23.0, spanning two
  minors. Both lockfiles move, including fuzz/Cargo.lock, which CI checks
  with --locked.
• The apply takes claim_change_set_for_apply instead of writing
  Approved -> Applying itself. mecmcp 0.22.0 made the claim the only legal
  route onto that edge -- it does the read and the write under one lock, so two
  applies cannot both read Approved and both push configuration -- and a
  plain update_change_set there is now refused outright. ApplyHandle::None,
  because a PAN-OS apply is synchronous and hands back no pollable handle: a
  crash mid-apply leaves an outcome only the device knows, which is what
  apply_without_handle records honestly.
• If the operation id cannot be persisted after the claim, the change set is
  settled to Failed rather than left claimed. Nothing has reached PAN-OS at
  that point -- the actions are applied afterwards -- so Failed is the true
  outcome, and without it the record would keep Applying across a restart with
  no operation_id and no OperationRecord, leaving the owner unable to retry,
  cancel or reconcile it through any normal API.
• ChangeSetRecord literals carry the new apply_without_handle field, and the
  #[cfg(test)] state writer calls write_state_for_test, since write_state
  is no longer public. The test-util feature is a dev-dependency, so a release
  build never enables it.
• A candidate PAN-OS rejected could still be committed. validate returned
  the failure as data -- Ok(PanosValidation { succeeded: false, .. }) -- and
  mecmcp's lifecycle records any Ok there as Validated, which is the state
  commit requires. A failed validation is now an error, so the apply stops.
  This also makes the dry_run_validation: true below true rather than an
  advertisement the implementation did not honour.
• PanosClient declares Atomicity::candidate_configuration() rather than
  inheriting the trait's nothing_guaranteed() default. PAN-OS edits a
  candidate configuration and commits it, so all three guarantees hold: the
  commit lands every staged change or none, the device validates before
  applying, and a revert is exact. Inherited, an approval prompt keyed on this
  would tell an operator that none of the three hold -- wrong in the direction
  that matters, since it describes weaker change control than PAN-OS provides.
• Moved quick-xml from 0.37 to 0.42 (#150), catching up four minors of parser
  and XML handling improvements.
• Dependency updates: rust base image to 1.98, distroless/cc-debian13 digest,
  actions/checkout to v7, uuid to 1.25.0.
• CI: Dependabot now ignores the git-pinned mecmcp-* crates (#153), which are
  intentionally pinned to a tagged release rather than tracking a moving ref.

Security

• Moved off the yanked chacha20 0.10.1, which was pulled from crates.io due
  to a critical security issue. The workspace now uses a patched version.

Upgrading

• A binary-only rollback to a build pinned at mecmcp v0.21.0 will refuse to
  start once any change set has been approved under this one. 0.23.0 signs a
  two-person approval with digest_version: 5, and a record carrying one stamps
  mutation-state.json as schema 6, which the v0.21.0 reader does not accept --
  correctly, since it cannot verify what it cannot parse. Roll
  mutation-state.json back alongside the binary, or take a snapshot of the
  guest before upgrading and restore that instead.

v0.11.0

Added

• SSDF evidence pipeline (mecmcp#292). The PAN-OS commit worker emits
  execution evidence, attributed to the applying request, and the evidence is
  flushed even when serving ends in an error. Receipts name the executor.

Security

• Tier-2 hardening. tokens.json path handling, audit HMAC key guarding,
  staged installs, a stale-secret scan, an SSDF drop-in, and systemd IP
  restrictions.
• The legacy token store is no longer shadowed by an empty one. An upgrade
  that found an empty primary could mask a populated legacy store, which reads
  as "every credential was rejected" rather than as a packaging fault.
• An operator is never told to erase their configured token store. The
  previous guidance could destroy live credentials.
• Packaging probes real egress enforcement rather than implying it.

Changed

• mecmcp 0.12.0 -> 0.19.0. That is the jump from the v0.10.0 baseline;
  0.17.0 was an intermediate untagged step. The fuzz workspace keeps its own
  lockfile and CI checks it with --locked, so it moves in the same commit.

Upgrade note — rolling back needs the state file, not just the binary

mutation-state.json carries a schema version. v0.10.0 links
mecmcp-changeset 0.12.0, whose reader accepts v1-v3 only. 0.11.0 links
0.19.0, which accepts v1-v4 and stamps v4 on any write to a store holding a
real approval.

So once this release has written state on such a store, reinstalling the
0.10.0 binary alone will not start — it rejects the file with
unsupported changeset state version 4.

Roll back with the Proxmox snapshot, which restores /var/lib along with
the binary. A binary-only downgrade is not a rollback path for this release.

• rmcp 3.1.2 -> 3.1.4.
• Toolchain and Dockerfile both move to 1.98.0, with the builder pinned to a
  full patch version and a toolchain sync check. MSRV enforcement corrected.
• A weekly advisory check for distroless digest drift.

Fixed

• Audit test capture uses a thread-local buffer, removing a callsite race.
• Only the resources actually held are named in errors, and the server says so
  when a retryable state cannot be restored.

Gap: 0.7.3, 0.7.4, 0.8.0, 0.9.0 and 0.10.0 were tagged but never written
up here. Their contents are recoverable from git log v0.7.2..v0.10.0 and
the release tags. Noted rather than reconstructed, so the omission is visible
instead of those five versions looking like they never existed.

---

Published retroactively from CHANGELOG.md; tagged 2026-08-25.

v0.10.0

• chore(release): 0.10.0
• build(deps): take h2 0.4.16 for RUSTSEC-2026-0258
• fix(auth): carry the mutation grant across the HTTP bearer boundary (#116)
• build(fuzz): update the fuzz lockfile for mecmcp v0.12.0
• feat(mutation): carry attribution and two-person evidence onto the commit log
• docs: document audit forwarding and where the trail goes
• chore: update fuzz/Cargo.lock for the v0.11.0 pin
• chore: re-pin mecmcp to v0.11.0
• chore(deps): bump rmcp from 3.1.1 to 3.1.2
• chore(deps): bump async-trait from 0.1.91 to 0.1.92
• chore(deps): bump rcgen from 0.14.8 to 0.14.9
• chore(deps): bump thiserror from 2.0.19 to 2.0.20
• chore(deps): refresh fuzz/Cargo.lock for mecmcp v0.10.0
• docs: document --lab-mode in the README
• chore(deps): mecmcp v0.10.0
• fix: --allow-insecure-bind never reached the transport

Changes since v0.9.0: 17 files changed, 768 insertions(+), 90 deletions(-)

---

Published retroactively; summarised from the commit range, as this repository keeps no CHANGELOG. Tagged 2026-08-18.

v0.9.0

• chore(release): 0.9.0
• chore: update the fuzz workspace lockfile to mecmcp v0.9.1
• chore: clear migration leftovers from the restored tests
• fix: revert unsafe_code lint and migrate tests to serve_on_loopback
• chore(deps): migrate to mecmcp 0.9.0
• feat: track config authority to prevent silently lost changes on plane-managed firewalls (#103)
• feat(transport): adopt mecmcp 0.8.0 generic scope preflight (#100)
• ci: SHA-pin the docker/* actions (#93) (#101)
• chore(deps): bump http from 1.4.2 to 1.5.0 (#97)
• chore(deps): bump clap from 4.6.4 to 4.6.5 (#96)
• chore(deps): bump docker/login-action from 4.5.2 to 4.6.0 (#94)
• chore(deps): bump rustls from 0.23.42 to 0.23.43 (#95)
• feat!: adopt mecmcp 0.7.2, and fail closed when HTTP has no caller (#98)
• chore(deps): bump docker/login-action from 4 to 4.5.2 (#88)

Changes since v0.8.0: 21 files changed, 1601 insertions(+), 668 deletions(-)

---

Published retroactively; summarised from the commit range, as this repository keeps no CHANGELOG. Tagged 2026-08-13.

v0.8.0

• feat!: adopt rmcp 3.1.1 on mecmcp 0.5.0, release 0.8.0 (#92)

Changes since v0.7.4: 8 files changed, 92 insertions(+), 71 deletions(-)

---

Published retroactively; summarised from the commit range, as this repository keeps no CHANGELOG. Tagged 2026-08-05.