#233 Generic webhook AuditSink, the first concrete sink (F8.5)

[Anonymous]

Originally created by: fu351
Originally owned by: Maqbool61

Doberman defines an AuditSink seam (storage/sinks.py) but ships no concrete sink, so every deployment that wants its decision log off-box has to write one. Add the reference implementation: a webhook forwarder.

Behavior

• Config-gated by an optional .doberman/audit_webhook.yaml (url, optional auth_env naming an env var whose value becomes the Authorization header, optional timeout_s). No file, or a malformed one, means the sink simply does not exist.
• emit() runs on the decision path and is synchronous, so it must only append the record to a bounded queue; a daemon worker thread POSTs with stdlib urllib.request. Queue overflow drops oldest and counts.
• HTTPS required unless the host is loopback. The token value comes only from the named env var: never stored in YAML, never logged.
• The POST body is exactly the record dict emit() was handed. It is already redacted upstream; the sink adds nothing and reads nothing else.
• emit_to_sinks consults built-in sinks after plugin discovery, with the same raising-sink isolation.

Tests must prove

• A synthetic secret never appears in any POSTed body.
• A wedged endpoint never delays or alters a decision (emit() returns before any network I/O).
• Drop-oldest counting; inert without config; the HTTPS rule; token absent from logs.

Honest scope: best-effort local buffering. Records lost on overflow or process exit are lost; this is a bridge to your own log pipeline, not a delivery guarantee.

[Anonymous]

Originally posted by: Maqbool61

Can i work on this?

[Anonymous]

• assigned_to: fu351

[Anonymous]

• assigned_to: Maqbool61

[Anonymous]

Originally posted by: fu351

Can i work on this?

Yes go ahead! I've assigned the issue to you, looking forward to reviewing your PR

[Anonymous]

Ticket changed by: fu351

• status: open --> closed