Skip to content

v0.99.32

Choose a tag to compare

View all tags
@github-actions github-actions released this 29 Sep 13:36
v0.99.32
261ebdf

Upgrade notes

  • A receiver on an older release cannot read version 2 envelopes ("unsupported
    encrypted payload version"). Upgrade listeners before senders.

Added

  • synapse aef: offline AEF evidence verification (K4-AEF-SURFACE).
    Anyone can verify a hub's native AEF receipts from files, without the hub.
    • aef trust writes the trust file from the hub's public key and hub id.
      aef-trust-v0.1 is a strict, documented contract: keys with revocation,
      validity window and sender scope, and logs bound to keys.
    • aef export copies the stored receipts, read-only, to JSON Lines.
    • aef verify runs the AEF verifier under one clock with a shared replay
      index (REPLAYED, CHAIN_CONFLICT). It exits 0 only if every receipt
      is VALID.
    • aef inclusion checks a receipt against a signed tree head.
    • Guide: docs/aef-verification.md, including what verification does not
      establish.
    • The normative verdict fixtures run through the command.

Security

  • Encrypted payloads are opened once (K3-F5). Before this change, an
    envelope captured on a route could be sent again on the same route and
    decrypted again; the route-bound AAD cannot tell.
    • synapse send --encrypt-key-file now writes version 2 envelopes. The AAD
      also binds the key id, a random 128-bit message_id and the sender's
      created_at_ms.
    • synapse listen --decrypt-key-file opens each one once through a durable,
      owner-only replay ledger per listener
      ($XDG_DATA_HOME/synapse/payload-replay/, or --replay-ledger PATH).
    • It refuses a replayed envelope, one older than 24 hours and one dated more
      than 5 minutes ahead. Admission happens only after authentication.
    • A version 1 envelope still decrypts, marked as not replay-protected;
      --require-replay-protection refuses it.
    • New core.payload_replay (PayloadReplayGuard, open_payload, error code
      payload_replay) and core.payload_crypto.authenticate_payload.
    • Verified on a real hub: the released 0.99.31 decrypts a replayed envelope
      twice, this change once.

Changed

  • The deployment guide's Caddy example, an internet-exposed hub behind a
    TLS-terminating proxy, now enrols seats and starts the hub with
    --expect-multi-seat --identity-trust FILE --require-identity-binding, as
    SECURITY.md requires for that posture. It also states that a peer hub or
    Fleet follower proving its id by client certificate needs direct WSS/mTLS or
    TCP/TLS passthrough, because the certificate stops at the proxy.
  • A restarted client passes strict sequence floors
    (CLIENT-SEQUENCE-PERSIST).     The Python client numbered per-message-auth
    frames from 1 in every process, so a hub with
    --message-auth-sequence-floor-mode strict refused a restarted agent
    (sequence_mismatch).
    • The sequence is now the wall clock in microseconds, or one more than the
      previous frame (core.message_auth.next_message_auth_sequence). No state
      file is needed; values stay below 2**53.
    • Proven through the public claim route: two client processes pass compat
      and strict, and a frame that falls back below the floor is still
      refused. On the old client code the strict case fails.
    • The --secure/--team-secure default stays compat while seats may run
      older clients.

Artifact checksums (SHA-256)

1736df59595d3f4dc609240ac242239c3a926f5db1c60d0eeed0b4662cc92f88  synapse_channel-0.99.32-py3-none-any.whl
8dbe7f6aa1a424b83cdb5dd17bd2c58a1f509b274afa1254321acbc670791260  synapse_channel-0.99.32.tar.gz
1ac60834afe1984364ae2b720416990dbe9e192cd957e97a974b454a992bf688  synapse-channel-v0.99.32-sbom.cdx.json
Assets 12
Loading