jx12n 4d9a26498e hush: one-time secret links the server cannot read

Paste a secret, get a link, send it. The first person to open it and press
Reveal sees the secret; the link dies at that moment. The recipient needs a
browser and nothing else — no account, no client, no installed tooling.

The server cannot read what it stores. AES-256-GCM happens in the browser and
the key lives in the URL fragment, which browsers never transmit, so hushd
holds ciphertext and no key material. That is a property of where the key sits
rather than a promise about our conduct, which is why there is deliberately no
endpoint accepting a plaintext secret and no server-side-encryption fallback:
two guarantees behind one URL would be worse than one honest guarantee.

Three decisions carry the design:

  * GET /s/{id} touches NO storage, not even to check existence. Slack, Teams,
    WhatsApp, iMessage and Outlook Safe Links all fetch a URL before a human
    sees it, so destroying on GET would destroy most secrets in transit and the
    recipient's "already used" would be indistinguishable from interception.
    Only POST /reveal consumes. Bot user-agent detection is an arms race;
    removing the side effect from GET is not. Pinned by
    TestGettingTheRevealPageNeverConsumesTheSecret.
  * Destruction is one Redis GETDEL, which is atomic. GET-then-DEL has a window
    where two simultaneous readers both win, and for a one-time secret that
    window is the product. The store contract demands atomicity and the same
    concurrency test runs against both implementations.
  * Missing, already-revealed, expired and evicted are ONE indistinguishable
    410. Separating them would confirm to a prober that a given link was real.

The secret id IS the capability, so secret.ID is a struct whose every
accidental path — %v, %s, String(), slog, json.Marshal — emits a redacted
handle or refuses, and the raw value needs an explicit Value(). The first
version tried to prevent leaks by implementing no String() at all; its own test
caught that Go's fmt prints unexported fields anyway, so forbidding the method
had removed the control rather than the leak.

Operationally: structured JSON on stdout in the fleet's wire format, which
Vector already collects with no annotation; six hush_* metrics on the chassis
registry with no id, IP or path in any label; five alert rules wired into
vmalert. The public Ingress enumerates /, /s/ and /api/ so /metrics, /healthz
and /readyz share the port but are unreachable from the internet — no
basic-auth middleware to maintain and get wrong.

Dependencies are vendored because go-chassis is private: the Woodpecker test
step and the in-cluster Kaniko build both run -mod=vendor with GOPROXY=off and
hold no git credential.

cmd/hush-mcp is a stdio MCP server doing the same client-side crypto locally,
so using hush from an agent preserves the same guarantee as using it from a
browser.

2026-09-03 00:08:38 -06:00

2.5 KiB

Raw Permalink Blame History

Maintenance Notifications

Seamless Redis connection handoffs during cluster maintenance operations without dropping connections.

Cluster Support

Cluster notifications are now supported for ClusterClient!

SMIGRATING: ["SMIGRATING", SeqID, slot/range, ...] - Relaxes timeouts when slots are being migrated
SMIGRATED: ["SMIGRATED", SeqID, src host:port, dst host:port, slot/range, ...] - Reloads cluster state when slot migration completes

Note: Other maintenance notifications (MOVING, MIGRATING, MIGRATED, FAILING_OVER, FAILED_OVER) are supported only in standalone Redis clients. Cluster clients support SMIGRATING and SMIGRATED for cluster-specific slot migration handling.

Quick Start

client := redis.NewClient(&redis.Options{
    Addr:     "localhost:6379",
    Protocol: 3, // RESP3 required
	MaintNotificationsConfig: &maintnotifications.Config{
        Mode: maintnotifications.ModeEnabled,
    },
})

Modes

ModeDisabled - Maintenance notifications disabled
ModeEnabled - Forcefully enabled (fails if server doesn't support)
ModeAuto - Auto-detect server support (default)

Configuration

&maintnotifications.Config{
    Mode:                       maintnotifications.ModeAuto,
    EndpointType:               maintnotifications.EndpointTypeAuto,
    RelaxedTimeout:             10 * time.Second,
    HandoffTimeout:             15 * time.Second,
    MaxHandoffRetries:          3,
    MaxWorkers:                 0,    // Auto-calculated
    HandoffQueueSize:           0,    // Auto-calculated
    PostHandoffRelaxedDuration: 0,    // 2 * RelaxedTimeout
}

Endpoint Types

EndpointTypeAuto - Auto-detect based on connection (default)
EndpointTypeInternalIP - Internal IP address
EndpointTypeInternalFQDN - Internal FQDN
EndpointTypeExternalIP - External IP address
EndpointTypeExternalFQDN - External FQDN
EndpointTypeNone - No endpoint (reconnect with current config)

Auto-Scaling

Workers: min(PoolSize/2, max(10, PoolSize/3)) when auto-calculated Queue: max(20×Workers, PoolSize) capped by MaxActiveConns+1 or 5×PoolSize

Examples:

Pool 100: 33 workers, 660 queue (capped at 500)
Pool 100 + MaxActiveConns 150: 33 workers, 151 queue

How It Works

Redis sends push notifications about cluster maintenance operations
Client creates new connections to updated endpoints
Active operations transfer to new connections
Old connections close gracefully

2.5 KiB Raw Permalink Blame History Unescape Escape