Signed · attested · reproducible

Security & supply chain

Artifacts your team can verify

This is why Haybarn exists. Every binary ships with checksums, a signature, and build provenance, hosted immutably — so a security team has something concrete to review before DuckDB goes into production.

Trust model

Two signing keys, both Haybarn's

Haybarn controls its own trust roots end to end — one key for releases, one for extensions. Neither is shared with upstream DuckDB.

Release signing key

A GPG RSA-4096 key signs the SHA256SUMS file on every GitHub Release. Import it once and you can verify every artifact you download.

Fingerprint

AC21 147B 0BAB F694 1225 ECBE C415 9506 8F3F 6537

Public key →

Extension signing key

A single Haybarn RSA key is embedded in the engine and signs every .duckdb_extension binary. The trust root is deliberately disjoint from DuckDB's.

  • • Only Haybarn-signed extensions load on the Haybarn engine.
  • • DuckDB-signed extensions will not load — and vice versa.
  • • Haybarn rebuilds and re-signs the whole community catalog with this key.

Provenance & integrity

Four ways to confirm a binary is what it claims

SLSA build provenance

Every release artifact carries a GitHub-signed provenance attestation that binds the binary to the exact workflow, repo, and commit that produced it. Verify it with one command — no Haybarn-side trust required.

Checksums + detached signature

Each release ships SHA256SUMS listing every artifact, plus SHA256SUMS.asc — a detached GPG signature of that file from the Haybarn release key.

Registry provenance

npm packages are published with provenance, and PyPI publishes carry PEP 740 attestations — so the same supply-chain trail follows the package channels, not just GitHub Releases.

Immutable hosting

Extensions are served from Cloudflare R2, where every deployed artifact lives at an immutable URL keyed by version and git sha. Nothing is overwritten in place.

Not yet

OS-native code signing (Apple Developer ID, Windows Authenticode) is not yet wired up. Integrity today comes from checksums, the GPG signature, and the build-provenance attestations above.

Verify it yourself

Two commands, end to end

Nothing here trusts query.farm at runtime — you check GitHub's provenance and a GPG signature you import once.

Build provenance

verify-provenance.sh 
# Verify GitHub's SLSA build-provenance for any release artifact
gh attestation verify haybarn_cli-linux-amd64.zip \
  --repo Query-farm-haybarn/haybarn

Checksums + signature

verify-release.sh 
# Import Haybarn's release signing key (GPG, RSA-4096)
#   fingerprint AC21 147B 0BAB F694 1225  ECBE C415 9506 8F3F 6537
gpg --import haybarn_release_signing.pub

# Confirm the checksums file is signed by that key
gpg --verify SHA256SUMS.asc SHA256SUMS

# Then check your download against the checksums
sha256sum -c SHA256SUMS

Download artifacts from GitHub Releases, and see which extensions are built and signed for the current engine on the status page.

Safer defaults

A curated catalog, vendor code opt-in

Supply-chain risk isn't only about signatures — it's about what runs without you asking. Haybarn's default catalog is the open-source set DuckDB's own CI builds, with third-party vendor extensions left out of the default install and autoload path.

Autoload stays narrow

A query referencing an extension won't silently pull in third-party vendor code — Haybarn's autoloadable list excludes it (motherduck is explicitly removed, with the rationale documented in source). You can still configure any extension yourself; it's just not on the default path.

Everything re-signed

The community catalog is rebuilt against the Haybarn engine and re-signed with the Haybarn key — the disjoint trust root is what makes the curation enforceable, not just advisory.

Auditable by construction

A small, reviewable delta from DuckDB

Haybarn is a hard fork kept as a small, curated commit stack on top of an upstream DuckDB release tag — so the difference from the engine you already trust is easy to read.

Curated commit stack

Haybarn's changes are branding, signing keys, repository URLs, and CI — a short stack on top of the upstream tag, not scattered edits. The engine source, SQL, and file format are unchanged.

SHA-pinned builds

Extension build-forks are pinned by 40-character commit SHA, not a moving branch — every build is explicit about exactly what source went into it.

Expert help

Reviewing Haybarn for production?

We help security and platform teams with supply-chain review, private signing keys, internal mirrors, and custom trust roots.

Consulting Schedule a call