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.
62 lines
2.8 KiB
Markdown
62 lines
2.8 KiB
Markdown
# procfs
|
|
|
|
This package provides functions to retrieve system, kernel, and process
|
|
metrics from the pseudo-filesystems /proc and /sys.
|
|
|
|
*WARNING*: This package is a work in progress. Its API may still break in
|
|
backwards-incompatible ways without warnings. Use it at your own risk.
|
|
|
|
[](https://pkg.go.dev/github.com/prometheus/procfs)
|
|
[](https://github.com/prometheus/procfs/actions/workflows/ci.yml)
|
|
[](https://goreportcard.com/report/github.com/prometheus/procfs)
|
|
|
|
## Usage
|
|
|
|
The procfs library is organized by packages based on whether the gathered data is coming from
|
|
/proc, /sys, or both. Each package contains an `FS` type which represents the path to either /proc,
|
|
/sys, or both. For example, cpu statistics are gathered from
|
|
`/proc/stat` and are available via the root procfs package. First, the proc filesystem mount
|
|
point is initialized, and then the stat information is read.
|
|
|
|
```go
|
|
fs, err := procfs.NewFS("/proc")
|
|
stats, err := fs.Stat()
|
|
```
|
|
|
|
Some sub-packages such as `blockdevice`, require access to both the proc and sys filesystems.
|
|
|
|
```go
|
|
fs, err := blockdevice.NewFS("/proc", "/sys")
|
|
stats, err := fs.ProcDiskstats()
|
|
```
|
|
|
|
## Package Organization
|
|
|
|
The packages in this project are organized according to (1) whether the data comes from the `/proc` or
|
|
`/sys` filesystem and (2) the type of information being retrieved. For example, most process information
|
|
can be gathered from the functions in the root `procfs` package. Information about block devices such as disk drives
|
|
is available in the `blockdevices` sub-package.
|
|
|
|
## Building and Testing
|
|
|
|
The procfs library is intended to be built as part of another application, so there are no distributable binaries.
|
|
However, most of the API includes unit tests which can be run with `make test`.
|
|
|
|
### Updating Test Fixtures
|
|
|
|
The procfs library includes a set of test fixtures which include many example files from
|
|
the `/proc` and `/sys` filesystems. These fixtures are included as a [ttar](https://github.com/ideaship/ttar) file
|
|
which is extracted automatically during testing. To add/update the test fixtures, first
|
|
ensure the `testdata/fixtures` directory is up to date by removing the existing directory and then
|
|
extracting the ttar file using `make testdata/fixtures/.unpacked` or just `make test`.
|
|
|
|
```bash
|
|
rm -rf testdata/fixtures
|
|
make test
|
|
```
|
|
|
|
Next, make the required changes to the extracted files in the `testdata/fixtures` directory. When
|
|
the changes are complete, run `make update_fixtures` to create a new `fixtures.ttar` file
|
|
based on the updated `fixtures` directory. And finally, verify the changes using
|
|
`git diff testdata/fixtures.ttar`.
|