Siglatch 1.0 Is Production-Ready for Its Use Case; 2.0-dev Extends the Wire

By The Grim Scalper · Tags: lab , siglatch , v1.0 , v2.0-dev , udp , security , access-control

Repo: github.com/linearblade/siglatch
Product page: www.m7.org/tools/siglatch

Siglatch is a signal-triggered control daemon for remote infrastructure: authenticated, encrypted UDP packets that grant, revoke, expire, or dispatch narrow actions without leaving a broad remote-admin surface standing forever.

If you need always-open control for everything, this is the wrong tool. If you need temporary, policy-scoped reachability and actions, it is built for that job.

Production recommendation

Track Status When to use it
1.0 (tag) Stable / production for intended use case Single-packet RSA-era control path, grant/revoke style actions, hardened knock → policy → script/builtin execution
2.0-dev Active development Hybrid bidirectional fragmented transport, multi-packet / stream-oriented payloads, richer protocol families and demux

Pin production deployments to the 1.0 tag unless you are deliberately evaluating 2.0-dev with eyes open.

What 1.0 is for (production use case)

Classic Siglatch loop:

  1. Client (knocker) builds a structured or unstructured payload
  2. Integrity via HMAC-SHA256; confidentiality via RSA-2048 on secure servers
  3. Daemon (siglatchd) size-checks, decrypts, validates structure/timestamp/nonce
  4. Policy gates user, action, server allowlists, optional wire-auth enforcement, IP rules
  5. Action runs as script, builtin, or static/dynamic object
  6. Optional keepalive / timeout semantics for temporary grants (e.g. open SSH for this IP, then revoke)

Typical actions teams wire today:

  • Grant / revoke / expire / flush IP access (firewall integration scripts)
  • Toggle maintenance surfaces
  • Dispatch reload, rotate, notify-style jobs
  • Dead-drop style payload delivery for constrained environments

Security posture (1.0 class path) includes non-blocking listen, packet size limits, HMAC + RSA layers, timestamp windows, nonce cache anti-replay, and base64 payload handoff to scripts. See docs/SECURITY.md in the repo for guarantees and known limitations (including rate limiting still treated as a hardening target).

What 2.0-dev adds (under development)

2.0 is not a cosmetic bump. It is a transport and packet model expansion on top of the same control-plane idea:

  • Stateless hybrid bidirectional fragmented UDP transport (m7mux and related codec work)
  • Multi-packet / stream-like or batched submission for payloads that do not fit a single classic envelope
  • User-defined protocol families and demux on the same daemon
  • Codec lineage v1 → v2 → v3 → v4 evolving from single RSA packet shapes toward hybrid CEK / AAD style constructions
  • Live reconfiguration builtins (reload, rebind, change setting, etc.) as the ops surface matures

In plain language: 1.0 is the production knock/control tool; 2.0-dev is building multi-UDP-packet streams and more customizable packet paths so the control bus can carry larger and more structured work without abandoning the narrow-blast-radius model.

Roadmap language in-tree also projects later DTLS / QUIC-class session polish (v3 direction). Treat that as direction, not a production promise, until tagged.

Operational notes

  • Dependencies: OpenSSL 3.x
  • Config is INI-style multi-server, actions, deaddrops, users, overflow policy
  • Scripts run with the daemon’s privilege model — treat the action registry like sudoers
  • Default samples may leave some wire enforcement knobs open for lab use; lock policy for production
  • License: MTL-10 (see repo LICENSE.md)

Bottom line

  • Ship 1.0 when you need production-grade temporary access and scoped UDP-triggered actions for the classic use case.
  • Track 2.0-dev when you need multi-packet streams, bidirectional fragmented transport, and custom protocol shape — and accept active-development risk.

Docs: README.md, docs/SECURITY.md, docs/FEATURE_SPEC.md, docs/OPERATIONS_*.md in the repository.

— M7 Lab