Security

Where to report issues, what we track, and our trust model.

Reporting vulnerabilities

fio is a 20+ year mature C codebase maintained by Jens Axboe (Linux kernel block layer maintainer). The canonical project lives at github.com/axboe/fio; that's where fio is developed, audited, and bug-fixed.

This repository (ljh-sh/fio) is only a static-build distribution. We don't maintain fio; we just compile it as fully self-contained static binaries.

Please report security issues upstream first:

If the issue requires coordinated disclosure that the upstream maintainers cannot provide, open a private GitHub Security Advisory on github.com/ljh-sh/fio/security — but expect us to forward it upstream first.

Trust model

We treat the upstream axboe/fio commit as the trusted artifact and pin the vendored tree to it (fio-3.41 → commit ed675d3).

Our build scripts do not modify the vendored source; the only outputs are configure artifacts (config-host.mak, config-host.h, FIO-VERSION-FILE) inside upstream/fio/, which are regenerated on every make distclean and have no bearing on the vendored source itself.

Build determinism + integrity

Every release archive ships a sibling *.sha256 file with a single hash entry. The combined SHA256SUMS aggregates per-archive hashes.

For a stronger check, you can:

  1. Verify the archive's .sha256:
    $ sha256sum -c fio-x86_64-linux-musl.tar.gz.sha256
    fio-x86_64-linux-musl.tar.gz: OK
  2. Verify SHA256SUMS is published as a release asset (signed by GitHub's release attestation).
  3. (Most authoritative) Reproduce the build locally:
    git clone https://github.com/ljh-sh/fio.git
    cd fio
    git checkout v0.1.0
    bash scripts/build.sh         # builds into upstream/fio/fio
    # Compare against your downloaded bin/fio via cmp(1) after gunzip'ing
    # the archive. Same toolchain major version produces byte-identical output.

Caveats

Per-release audit

See audit.html for the source-level audit that landed with each tagged release.