Security

Every relate CLI release ships a SHA256SUMS manifest signed with one Ed25519 key. install.sh and relate upgrade check that signature against a copy of the key pinned inside themselves, check that the manifest names the release being installed, check the binary's SHA-256, and install nothing if any check fails. The macOS binaries are also signed and notarized by Apple. No security policy, supported-versions statement, or vulnerability disclosure address is published yet, and no release carries a software bill of materials (SBOM) or SLSA provenance.

Synopsis

Release signing key

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHgv/GHY5mtv/HopH/J/T7KrTT7eOVFEG2ueT4iRKwbK relate-release

All three copies are the same bytes. Its fingerprint, computed from the key:

echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHgv/GHY5mtv/HopH/J/T7KrTT7eOVFEG2ueT4iRKwbK relate-release' > release-signing-key.pub
ssh-keygen -lf release-signing-key.pub

256 SHA256:BfnIA0YD0h+ldihdq8V1k/xFY91lm8mRCuVS21+3kzA relate-release (ED25519)

The signer identity and the signature namespace are both relate-release, from 0.1.0, the first relate-named release, on. Releases up to and including 0.16.1 were published under the earlier name, as cypherlite-<os>-<arch>, signed with the same key under the identity and namespace cypherlite-release, with the manifest header # cypherlite-release-version: . A new key ships inside a release. A binary installed before a key change still trusts the old key, so its relate upgrade refuses releases signed with the new one; install.sh, which carries the new key, installs them.

What install.sh and relate upgrade check

install.sh downloads SHA256SUMS and SHA256SUMS.sig first and makes the first two checks before it downloads the binary. It installs by writing a temporary file in ~/.local/bin and renaming it into place, so an interrupted install leaves no partial binary.

A manifest with no version line is accepted, with a warning, only for releases up to v0.14.0, which predate the line. install.sh compares version numbers alone, and relate restarted them at 0.1.0, so the rule also covers relate 0.1.0 to 0.14.0; every relate release so far carries the line.

Manual verification

The same three checks run by hand with curl, ssh-keygen, and sha256sum. For a release on Linux amd64, from 0.1.0 on, with VERSION holding the release's version number (without the v), the commands and their expected output are:

ASSET=relate-linux-amd64
BASE="https://github.com/relatedb/relate/releases/download/v$VERSION"
curl -sSfLO "$BASE/$ASSET"
curl -sSfLO "$BASE/SHA256SUMS"
curl -sSfLO "$BASE/SHA256SUMS.sig"
echo 'relate-release ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHgv/GHY5mtv/HopH/J/T7KrTT7eOVFEG2ueT4iRKwbK relate-release' > allowed_signers
ssh-keygen -Y verify -f allowed_signers -I relate-release -n relate-release -s SHA256SUMS.sig < SHA256SUMS
head -n 1 SHA256SUMS
grep "  $ASSET\$" SHA256SUMS | sha256sum -c -

Good "relate-release" signature for relate-release with ED25519 key SHA256:BfnIA0YD0h+ldihdq8V1k/xFY91lm8mRCuVS21+3kzA
# relate-release-version: v<version>
relate-linux-amd64: OK

In the output, <version> is that version number. The other assets are relate-linux-arm64, relate-darwin-arm64, relate-darwin-amd64, and relate-windows-amd64.exe. On macOS, shasum -a 256 -c - takes the place of sha256sum -c -. The Pinned binary tab of Install relate gives the same steps with the install that follows them. The release URLs are launch-day targets: the repository is private until launch. The checks for a release up to and including 0.16.1 use that release's names instead: the cypherlite-<os>-<arch> asset, cypherlite-release as the identity, the namespace and the allowed_signers principal, and # cypherlite-release-version: as the header.

Code signing and notarization

SHA256SUMS lists the five CLI binaries only. The other artifacts are not in it.

Provenance and software bill of materials

No release publishes a software bill of materials (SBOM), and no release publishes a build provenance attestation in the SLSA format. The release workflow has no step that produces either.

Supported versions and security fixes

No supported-versions statement and no security-fix policy is published. Releases are cut forward from the main branch, and the release process describes no way of patching an older release line. relate is pre-1.0; Project gives the versioning policy.

Reporting a vulnerability

No address for reporting a vulnerability exists yet. It is to be published at launch, together with https://relatedb.ai/.well-known/security.txt, which the site builds once a security contact is recorded. Until then the relate repositories are private, so there is no public issue tracker either.

Served surfaces

relate serve hosts the HTTP Query APIHTTP Query API The JSON-over-HTTP statement endpoint relate serve --http <port> hosts, in the shape of Neo4j's Query API v2: POST /db/<name>/query/v2. Read more in the glossary, MCPMCP The Model Context Protocol, which agent hosts use to call tools; relate serve --mcp exposes a store as read_cypher, get_schema and write_cypher. Read more in the glossary, and BoltBolt Neo4j's binary client protocol; relate serve --bolt <port> speaks it, so Neo4j's drivers and Neo4j Browser can run statements against a relate store. Read more in the glossary on one open storestore A relate database: a directory, a single .rl file, or :memory:, opened with --database. Read more in the glossary. Its defaults:

--mcp stdio serves MCP on stdin and stdout for an MCP host, with no authentication challenge. A host configuration that opens a store --read-only keeps an agent from writing to it; the agent safety guide has the permission matrix across the CLI and MCP.

Engine defaults that limit reach

Agent-facing files on the site

See also

• Install relate: the install commands, with the Pinned binary steps
• Privacy and telemetry: what the CLI reports, and what never phones home
• Keep an agent safe: read-only and safe mode for agents
• Project: license, versioning, and release process
• Limitations: what the engine and its surfaces do not do