trustmebro: the fast install pipes a tarball and skips the checksums it publishes, the Makefile builds a Windows asset the table omits, and go.mod asks for Go 1.27

The fast install skips the checksums the project publishes

The prebuilt path is two lines: a `curl` of the `latest` release tarball piped straight into `tar xz`, then `./trustmebro install`. The next section states that checksums are published with each release in a file called `SHA256SUMS`, and the Makefile's release target is what generates it, by running `sha256sum` over every tarball in `dist`. So the integrity artefact exists, is produced by the build, and is not consulted by the documented install. The tarball name carries no version, and that is deliberate: a comment in the Makefile explains that version-less asset names keep the `latest` download URL stable across releases. That reasoning is sound, but it also means the URL always resolves to whatever was uploaded most recently, which is precisely the case where a checksum earns its keep. The removal path shows the level of care the project applies elsewhere:

trustmebro uninstall          # Remove shims and PATH wiring
trustmebro uninstall --purge  # Also remove the binary, config, and state

The Makefile builds a Windows tarball that the release table omits

The release target loops over five target triples:

for t in linux/amd64 linux/arm64 darwin/amd64 darwin/arm64 windows/amd64; do \

and appends an `.exe` extension when the operating system is windows, then tars the result into a version-less archive and removes the staging directory. Five artefacts are produced. The asset table on the page lists four: Linux x86-64, Linux ARM64, macOS Intel, and macOS Apple Silicon. Windows is absent from the table while being present in the build, which makes it the one platform where the documented surface and the produced surface disagree. The prose covers Windows in a different way, saying the installer targets Unix shells and that the Windows binary is experimental without equivalent shell startup integration. So the binary is built and checksummed but not catalogued, and the sentence about it being experimental is the only place a reader learns it exists.

go.mod asks for Go 1.27 and the page names no minimum

The module directive is `go 1.27`, and the module requires exactly one dependency, `gopkg.in/yaml.v3` at `v3.0.1`. Nothing else. For a program whose job is to sit between an agent and the real binaries, one YAML parser is a genuinely small surface, and `go.sum` is committed alongside it. The gap is on the documentation side. The build-from-source route is `make install`, which calls `go build`, and the alternative route is `go install github.com/DavidCarliez/trustmebro@latest` followed by running the binary from `~/go/bin`. Neither line states a Go version, and the release asset table gives no hint either. So a reader on an older toolchain discovers the requirement from the module file or from a toolchain error, which is the wrong place to learn it.

A flat root package holds the generator, the namespace, and the installer

The repository is a single Go package at the module root rather than a command directory layout: `main.go`, `config.go`, `gen.go`, `install.go`, `lab.go`, `log.go`, `match.go`, and `run.go`, with `integration_test.go` and `trustmebro_test.go` beside them in the same package. The Makefile builds `.` accordingly. Three of those files are the substance of the tool and none is named in the documentation. `gen.go` is where the fabricated resolver output comes from, since the capability list credits realistic `dig`, `nslookup`, and `host` output. `lab.go` is the Bubblewrap namespace. `install.go` is the part that rewrites shell startup files. Reading the page tells you what the tool does; reading those three files tells you how, and how is where the risk lives. There is also a `Makefile`, a `CHANGELOG.md`, and an `assets/` directory, and `.github/` for workflows.

Two marker strings and two domains for what is presented as one demo rule

The quick start shows a lookup against a domain under `trustmebro.test` returning a quoted TXT value ending in the digits `7f3a9`. Later, the configuration example shows a rule named `txt marker` matching a glob under `example.test` with a TXT record whose value ends in those same digits and reads differently. The audit log sample then shows a decision for `marker.trustmebro.test` attributed to the rule named `txt marker`. So one walkthrough uses a different domain from the one the config example matches, and the log entry attributes to a rule whose own match field would not have selected it. Three artifacts, three slightly different versions of the same demonstration, and the shared suffix is the only thing that ties them together. Nothing here breaks the tool, and that is the point: a reader copying the quick start works, and a reader cross-checking the samples against each other finds three inconsistencies.

The installer rewrites shell startup files, and the scoped mode is Linux only

Installation writes a CLI, a shim directory, a config file, and a state directory under the user's home, then prepends the shim directory to supported shell startup files. Login shell files are included, and the reason given is that agents commonly execute commands through non-interactive `bash -lc` sessions. That means the default install changes what `dig` resolves to in every future shell in every terminal, not just inside a test run, which is the invasive shape. The scoped alternative is `trustmebro lab`, which runs a shell or an agent inside a temporary interception namespace built with Bubblewrap, shadowing both PATH lookups and discovered absolute paths so that `command -v` cannot be used to route around it. That mode is Linux only, requires `bubblewrap` from the package manager, and says plainly that it is an interception namespace and not a security sandbox, because it reuses the host filesystem, the current workspace, the network, the environment, and the agent's credentials.

One environment variable disables everything, and a bad config exits 78

Configuration is parsed strictly. Unknown fields, unsafe shim names, invalid actions, and malformed rules make `trustmebro check` fail, and an installed shim that meets an invalid config blocks the command and exits with status 78, the conventional configuration-error code. `TRUSTMEBRO_CONFIG` redirects the config file for one process or test run. A second variable, `TRUSTMEBRO_DISABLE=1`, is documented as something to set only when you explicitly need to bypass the config and run the real command. Read together, those two lines describe a strict system with a single-variable off switch, and an agent that controls its own environment can set it. The default action is `passthrough` and the default `shim_commands` list is only `dig`, `nslookup`, and `host`, so an unmatched or unshimmed command reaches the real binary through `exec`, which is the correct default. Every decision is written to a timestamped JSONL log with the command, domain, rule, mode, and exit status.

Editorial conclusion

Use this in an environment you own, for a question you are authorised to ask, and prefer the scoped mode. The design decisions worth keeping are the ones about not overclaiming: a statement that the namespace is not a security sandbox, a strict config parser that refuses to guess, and a default action of passthrough so an unmatched command does the real thing. The decisions to watch are the machine-wide shell startup edits in the default installer, the single environment variable that disables the whole mechanism, and the install one-liner that skips the checksum file shipped alongside it. Before you run any of it, read what lab mode deliberately reuses from the host, because it reuses the filesystem, the network, the environment, and the agent's own credentials.

Frequently asked questions

Official sources

1. DavidCarliez/trustmebro on GitHub
2. Issues
3. License: MIT
4. README
5. Releases