4d9a26498e
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.
|
||
|---|---|---|
| .. | ||
| circuit_breaker.go | ||
| config.go | ||
| errors.go | ||
| example_hooks.go | ||
| FEATURES.md | ||
| handoff_worker.go | ||
| hooks.go | ||
| manager.go | ||
| pool_hook.go | ||
| push_notification_handler.go | ||
| README.md | ||
| state.go | ||
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 disabledModeEnabled- 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 addressEndpointTypeInternalFQDN- Internal FQDNEndpointTypeExternalIP- External IP addressEndpointTypeExternalFQDN- External FQDNEndpointTypeNone- 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