What changes for you in FosterStack Cache v0.3.0

You run FosterStack Cache for Gradle or Maven builds and you want to know what an upgrade to v0.3.0 changes. Three things may matter on your side: check them before you upgrade.

DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.

Check these before you upgrade

• Linux only. v0.3.0 ships Linux archives (amd64 and arm64) and no macOS archive. On a Mac, run the Linux container image under Docker Desktop.
• No -debug image. v0.3.0 ships the production and fips images only. They hold only the fscache binary, with no shell, so look inside a running container from outside it with kubectl debug or docker debug; the README has a section on it.
• Inside the data folder. The data folder path is the same, but temporary files of writes in flight now live in a +tmp folder inside it.

Fixed in this release

This release is built with Go 1.27.3. It fixes GO-2026-6809 (CVE-2026-111943) in Go's standard library: crypto/x509 now distrusts compromised intermediate certificates. The fix ships in this release; there is no separate patch release for it. The CA certificate bundle is updated too (Wolfi's ca-certificates-bundle 20260909-r3), which removes three eMudhra roots: emSign Root CA C1, emSign ECC Root CA C3 and emSign ECC Root CA G3.

What is new for Gradle and Maven users

• Optional HTTPS. Set FSCACHE_TLS_CERT and FSCACHE_TLS_KEY (both or neither) and the server serves HTTPS, TLS 1.2 or later.
• Clearer start-up. The server opens its listener first, warns about an FSCACHE_* variable it does not know, and reports how many uploads it found.
• Safer disk handling. A failed recovery check, or an error while serving or shutting down, keeps the "unclean" marker so the next start checks again. Temporary files no longer share a name space with cache keys, and keys whose last part starts with .. are stored in a fixed place.
• Disk-trouble metrics. store_writable, store_free_bytes and put_errors_total{reason} are new, and the store gauges are present from start-up.

What stays the same

The Gradle and Maven protocols stay as they are, and every FSCACHE_* setting you use today keeps its meaning. A request with more than 500 header values has been rejected with 431 (Request Header Fields Too Large) since 0.2.2, because of Go 1.27; Gradle and Maven send far fewer.

Kept patched

We keep FosterStack Cache patched. The server does not update itself, so watch the repository's releases on GitHub. Our target for vulnerable dependencies is 48 hours from disclosure; the scope is in SECURITY.md.

How the release is built

Signed at every stage, verified together at release. The image is built from signed packages, with no base image. Each build (one per architecture, and the assembly of the images) runs as its own job on a fresh virtual machine that GitHub provides and then discards. The key that signs the software packages inside the images (the package-signing key) exists in one place only, the release job's environment, and only one step in it receives the key. That job is handed only the exact files the build made, never the files from the second, independent rebuild. The comparison between the build and the rebuild runs in a job that holds no secrets and has no permission to publish. The signatures on the images, and on the checksum list that covers every release archive, are a different thing: they use short-lived certificates tied to the workflow that made them, so no long-lived key signs them. (The archives are not signed one by one; the signed checksum list covers each of them.)

This is designed against the build-isolation asks of SLSA and NIST SP 800-53; we claim no certification and no compliance. You can check the release yourself: see verify a release yourself and how we build.

What this release does not do

• The jobs are separated at the level of a virtual machine, not on separate physical hardware.
• The package signing key is not rotated automatically.
• The release pipeline's own signing tools are not FIPS-validated. (The -fips image uses Go's FIPS 140-3 module, which is a different claim.)
• There are no macOS or Windows binaries.

Upgrading

The upgrade steps are the same as for any release: pull the new tag and start it on the same volume. See upgrading from 0.2.x to v0.3.0 for what to check first.

Related: changelog, security policy, the FIPS 140-3 build and installing without internet access.

Moving off the free Build Cache Node? See what the end of life means and the migration guide.