Project status and release notes
Ce contenu n’est pas encore disponible dans votre langue.
Tobby is released and under active development. Milestones 1–6 are delivered;
the current release line is v0.6.x. The table below is rendered from a
single data file (status.yaml) and feeds every status badge on this site —
including the filtered security view on the
security one-pager. If a page and this table ever
disagree, this table is right and the page has a bug.
Feature status
Section titled “Feature status”Status as of v0.6.0 (2026-11-12)
| Feature | Status | Milestone |
|---|---|---|
| 1.1 Secure build chain (reproducible, SLSA L3, signed SBOM) | Available | — |
| 1.2 Operable application foundation (layered config, JSON logs, probes, metrics) | Available | — |
| R-09 End-to-end run identifier | Available | — |
| R-12 Security audit logFoundation, authentication, token and media-override events, then scan refusals, session and token expiry, local sign-in under federation and store verification with v0.6.0. | Available | — |
| 1.3 Embedded OCI registry with canonical relocation layout | Available | — |
| 1.4 Recipe / Retriever format specification (Apache-2.0)Public draft, v1alpha1, separate repository. | Available | — |
| 1.5 Five-level test pyramid and blocking quality gates | Available | — |
| 1.6 Crucible: disposable replica of the target environment | Available | — |
| 2.1 Server-rendered web UI, bilingual EN/FR, no Node | Available | — |
| 2.2 Content browsing (repositories, tags, platforms, digests) | Available | — |
| R-03 Actionable error taxonomy (TBY-* codes, bilingual) | Available | — |
| R-06 Search and filters with strict UI/API parity | Available | — |
| 2.3 On-demand unit import with platform selection | Available | — |
| 2.4 Persistent task tracking with logs and resumption | Available | — |
| 2.5 Versioned REST API /api/v1 with self-served OpenAPI | Available | — |
| R-01 Secure guided first start (no open UI, tool-computed hashes) | Available | — |
| R-34 Interactive first start (tobby quickstart) | Available | — |
| R-35 System packages (.deb/.rpm/.apk) as release assets | Available | — |
| 3.1 Strict recipe and retriever validation (SDK, unknown field = rejection) | Available | — |
| 3.2 All four ingredient kinds (ContainerImage, HelmChart, OCIArtifact, FileSet) | Available | — |
| 3.3 Version resolution and per-digest differential sync | Available | — |
| R-23 FileSet packaging guide (reproducible archives, standard tooling) | Available | — |
| 3.4 Cosign signature verification at entry (trust roots, scopes, both layouts) | Available | — |
| R-26 Store format compatibility guarantee across versions | Available | — |
| R-10 recipe lint and cookbook publication guide | Available | — |
| 3.5 Source-to-destination mapping table and zone cascade | Available | — |
| 3.6 FileSet HTTP serving — OS package repository (/files/) | Available | — |
| 4.1 Continuous promotion service between connected zones | Available | — |
| 4.2 Registry allowlist, refused before any transfer | Available | — |
| 4.3 Authentication and RBAC, secure by default (basic, tokens, three roles) | Available | — |
| R-29 Fine-grained resume of large downloads (HTTP Range) | Available | — |
| R-36 Recipe publication from the CLI (tobby recipe push) | Available | — |
| R-37 Recipe document visible in the interface (digest, copy, download) | Available | — |
| R-40 Recipe import from the interface | Available | — |
| R-39 recipe cook: recipe-authoring toolingIn development in the recipe-spec repository. | Upcoming | — |
| 4.4 Enterprise network: authenticated proxies, private PKI, server TLS | Available | — |
| 4.5 Reference deployment (hardened Helm chart and raw manifests) | Available | — |
| 5.1 Mirror synchronization onto a transportable store | Available | — |
| R-02 Media screen: guided operator journey with per-step verdicts | Available | — |
| 5.2 Pre-flight checks: deduplicated volume vs media space, filesystem refusals | Available | — |
| R-05 Embedded offline documentation and troubleshooting (/help) | Available | — |
| R-08 Stable CLI contract (--output json, published exit codes) | Available | — |
| R-04 Plan mode: full dry-run without side effects | Available | — |
| R-28 Media identity and freshness (stale media refused by default) | Available | — |
| R-16 Secrets never travel on the transportable store | Available | — |
| 5.3 Zone identity guard and media inventory | Available | — |
| R-19 Fine-grained blocking on a tampered medium (per-recipe verdicts) | Available | — |
| 5.4 Destination-side operation (full re-verification, then differential push) | Available | — |
| R-41 Pack a directory into a served FileSet (tobby fileset pack) | Available | — |
| 5.5 OCI image layout export/import and audited store reset | Available | — |
| R-33 Transit store housekeeping (retriever-aligned cleanup, disk threshold) | Available | — |
| 5.6 Windows workstation for the mirror journey (winget, Scoop)The mirror journey is validated on a Windows CI runner and the single binary is released for it. Both workstation channels are published: Scoop — `scoop bucket add tobby https://github.com/tobby-fetch/scoop-bucket` — and winget — `winget install tobby-fetch.tobby`, in the community index since 2026-09-26. winget can lag a few days behind a release, since each version is reviewed in an index maintained by other people. | Available | — |
| 6.1 Vulnerability scanning with policy (Trivy, blocking or advisory)Delivered in v0.6.0. | Available | — |
| R-13 Guaranteed freshness of the vulnerability databaseDelivered in v0.6.0. | Available | — |
| R-14 Authentication hardening (rate limiting, session and token expiry)Rate limiting since v0.4.2; idle session expiry, optional token expiry and their audit events with v0.6.0. | Available | — |
| 6.2 Offline vulnerability database, carried by Tobby itselfDelivered in v0.6.0. | Available | — |
| R-25 Tobby updates through its own channel, across the air gapDelivered in v0.6.0 — the first release published recipe-ready. | Available | — |
| R-22 Reduced-trust content stays visibly marked everywhere | Available | — |
| R-20 Continuity when the enterprise directory is down | Available | — |
| 6.3 Enterprise identity: OIDC, then SAML 2.0 | Available | — |
| R-07 Printable transfer report (bilingual, marked as unsigned aid)Delivered in v0.6.0. | Available | — |
| R-31 On-demand store integrity verification with timestamped report | Available | — |
| 7.1 UI polish and consumption aids (mapping exports, registries.yaml snippet) | Upcoming | J7 |
| 7.2 Complete bilingual documentation (EN/FR, CI-checked completeness) | Upcoming | J7 |
| R-30 One-step redacted diagnostic bundle | Upcoming | J7 |
| R-11 Integration and monitoring kit (signed OpenAPI, metrics reference, alerts) | Upcoming | J7 |
| R-32 Clock-sanity detection in isolated zones | Upcoming | J7 |
| R-27 Instance backup and tested rebuild procedure | Upcoming | J7 |
| R-15 Scoped, expiring vulnerability exceptions (VEX-convergent) | Upcoming | J7 |
| 7.3 Hardening proven by tests (fuzzing, CSRF, OCI conformance suite) | Upcoming | J7 |
| R-21 Documented emergency path (scoped, visible, organization-signed)Documentation-only feature; no code path. | Upcoming | J7 |
| R-17 Per-content provenance and trust class, visible everywhere | Upcoming | J7 |
| 7.4 Adversarial acceptance and version 1.0 (spec frozen at v1) | Upcoming | J7 |
Version trains
Section titled “Version trains”Each milestone maps to a minor release line: milestone N ships as v0.N.x. Patch releases within a train carry fixes and hardening only, never new features.
| Milestone | Train | Status |
|---|---|---|
| 1 — Foundations | v0.1.x | Delivered (v0.1.0, 2026-08-11) |
| 2 — User-experience preview | v0.2.x | Delivered (v0.2.0, 2026-08-12) |
| 3 — Recipe engine | v0.3.x | Delivered (v0.3.0, 2026-08-16) |
| 4 — Passthrough | v0.4.x | Delivered (v0.4.0 → v0.4.2) |
| 5 — Mirror & air-gap | v0.5.x | Delivered (v0.5.0 → v0.5.2) |
| 6 — Hardened controls & enterprise identity | v0.6.x | Delivered (v0.6.0, 2026-11-12) |
| 7 — Finishing, documentation & acceptance | v0.7.x → 1.0.0 | Upcoming |
Observed cadence. The first five milestones shipped between 2026-08-11 (v0.1.0) and 2026-08-27 (v0.5.0), with two hardening patches along the way (v0.4.1 on 2026-08-18, v0.4.2 on 2026-08-22) and two maintenance releases after them (v0.5.1 on 2026-11-07, v0.5.2 on 2026-11-09); milestone 6 followed on 2026-11-12 (v0.6.0). That is the cadence of the initial development phase, not a commitment: each milestone ships when its acceptance scenarios pass on the crucible, not on a date.
Path to 1.0. One milestone remains: milestone 7 closes with finishing work, complete bilingual documentation, and an adversarial acceptance run on the release candidate. Version 1.0.0 freezes the four public surfaces (CLI, API, configuration, storage layout) under SemVer — the release and compatibility policy is the canonical home for what is stable already and what freezes at 1.0.
Release notes
Section titled “Release notes”Each milestone train has a raw acceptance report; they are published under acceptance reports. The full changelog lives in the repository (CHANGELOG.md).
v0.6.0 — 2026-11-12 (milestone 6)
Section titled “v0.6.0 — 2026-11-12 (milestone 6)”Hardened controls and enterprise identity: every image is scanned for vulnerabilities under a policy, and people sign in through the organization’s identity provider.
- Vulnerability scanning with a policy (6.1, 6.2, R-13). Every
container image is scanned at retrieval by a pinned, offline Trivy run
out of process. The policy is advisory by default — findings are
reported, nothing is withheld — and becomes blocking with
scan.mode: blockor a CVSS threshold posed by a Retriever or a recipe, with hand-listed exceptions. A refusal withholds the whole recipe. The database and the scanner cross the air gap by thetobby-systemchannel, and a stale database is never silent. - Scanning follows the content, not the declared kind
(ADR-0017):
an image declared as an
OCIArtifact, or adocker savearchive carried in aFileSet, is recognized by its bytes and scanned under the same policy. - Enterprise sign-in: OpenID Connect and SAML 2.0 (6.3), off by default, beside local accounts and tokens; groups map onto the three roles. An unreachable provider never stops the instance nor ends a session (R-20); idle sessions expire and tokens can (R-14).
- On-demand store integrity verification (R-31):
tobby store verify, the Store integrity screen and the API re-hash every blob, check every recorded recipe’s manifests and signatures, and list orphans, in a timestamped report — reading only, never repairing. - Reduced-trust content stays marked (R-22): a recipe admitted unsigned under a relaxed trust scope carries a reduced-assurance marker in reports, screens, logs, metrics and the media manifest.
- The printable transfer slip (R-07): the Media screen as a bilingual HTML or text document, unsigned and saying so.
- Tobby updates through its own channel (R-25): every release is published recipe-ready, binaries included, so a zone carries Tobby across the air gap under its own signature. Nothing updates by itself.
v0.5.2 — 2026-11-09 (maintenance)
Section titled “v0.5.2 — 2026-11-09 (maintenance)”- The Helm chart is published with every release as a signed OCI
artifact:
helm install tobby oci://ghcr.io/tobby-fetch/charts/tobby --version 0.5.2. The chart version is the Tobby version. - The chart deploys the right image again. Its default image had stayed at v0.3.0 since milestone 3 (B-035); a check now fails the build and the release when the chart lags.
v0.5.1 — 2026-11-07 (maintenance)
Section titled “v0.5.1 — 2026-11-07 (maintenance)”No new feature: the toolchain moves to Go 1.27.3 and every Go dependency, pinned tool and CI action to its latest release, and the whole milestone 1–5 crucible was replayed on the result.
- Two web-interface fixes found by the static analysis that came with
the new tools. The post-login redirect could be sent to another host by
a link spelled the way a browser, but not a string comparison, reads as
protocol-relative (B-033); and request bodies were not bounded, so the
sign-in form accepted an unauthenticated upload spilled to disk without
limit (B-034). The language and theme cookies are now
HttpOnly. - The weekly image rebuild works again: it had been failing since its packaging tool started requiring a newer Go than the release it rebuilds.
v0.5.0 — 2026-08-27 (milestone 5)
Section titled “v0.5.0 — 2026-08-27 (milestone 5)”Mirror and air-gap delivered: the second complete use case, from a mirror synchronization onto a transportable store to a verified push inside an isolated zone.
- The medium and its verification. Every mirror synchronization writes a media manifest — an inventory of every covered file, the recipes fulfilled with their pinned digests, the zone identity, the media identifier and the run. It is deliberately unsigned and nothing rests on it; the destination re-derives authenticity from the recipes’ cosign signatures against its own trust roots and from every file’s own content address (ADR-0016). Blocking is decided per recipe (R-19): a medium carrying two deliveries where one arrived damaged still delivers the intact one.
- Operation on the isolated side (FR-052):
tobby media verify,tobby media import, their/api/v1/mediamirrors, and the guided Media screen — Verify, Report, Push, with the Push control absent until a verdict clears a delivery. - An unverified medium serves nothing. A destination instance holding a
transported store withholds
/v2/and/files/until verification clears it, answering403withTBY-MED-030and the way out, while staying live and ready so the screen that fixes the condition is reachable. - Pre-flight and plan mode (FR-055, R-04): volumes computed per recipe and
deduplicated by digest against the target’s free space and filesystem
capability, and
tobby sync --dry-runproducing the full report of a synchronization to come with no side effect and its own exit code. - A command line under a stable contract (R-08):
--output jsoneverywhere, a published exit-code table generated from the code,--wait, and a guaranteed non-interactive mode. - OCI image layout export and import (FR-051), audited
store reset (FR-046), retriever-aligned
pruning with a store occupancy threshold (R-33), and
tobby fileset pack(R-41). - The documentation travels inside the binary (R-05):
/helpserves this whole corpus offline, in both languages, on an instance with no route to anything. - Windows is a validated platform, not a compiled one (5.6): the mirror
journey runs end to end on a Windows CI runner, against a genuine FAT32
volume. Eight defects that first real run found are fixed. The winget and
Scoop manifests are built and attached to each release. Both channels have
since been published — Scoop, then winget as
tobby-fetch.tobbyon 2026-09-26 — see supported platforms.
v0.4.2 — 2026-08-22
Section titled “v0.4.2 — 2026-08-22”Hardening release, no new features. A point-in-time quality audit was run between milestones 4 and 5 and this release carries its fixes:
- Fixed defects: a data race between task persistence and the parallel
ingredient sync (B-016), and a garbage collector that could sweep blobs of
an in-flight transfer (B-017). Also fixed: a task-runner panic could kill
the whole service, CLI usage errors exited with the wrong code, and
tobby recipe pushsurfaced raw transport errors instead of taxonomy blocks. - Hardening: task history retention and pagination, rate limiting on
failed authentication attempts (before the password hash is computed),
security headers with a hash-based Content-Security-Policy, a progress
watchdog on stalled downloads, and
govulncheckplus a full-history secret scan added to the quality gates.
v0.4.1 — 2026-08-18
Section titled “v0.4.1 — 2026-08-18”One fix: an instance serving the generated fallback TLS certificate could not adopt a replacement from the administration screen (FR-082). Adoption is now offered into the state directory, as a deliberate separate step.
v0.4.0 — 2026-08-18 (milestone 4)
Section titled “v0.4.0 — 2026-08-18 (milestone 4)”Passthrough delivered: the continuous promotion service, the registry allowlist, account lifecycle with RBAC in the UI and API, enterprise network support (authenticated proxies, private CAs, server TLS), fine-grained resume of large downloads, recipe publication from the interface, the reference Helm chart, and a browser-driven UI regression suite.
- Fixed defects: trust scopes matched differently on the two halves of a promotion (B-014), and Sigstore bundle signatures were left behind by the copy one hop downstream (B-015) — both caught by crucible runs before release, not by users. Also fixed: task screens that never stopped polling (B-012) and file downloads hijacked by boosted navigation (B-013).
v0.3.0 — 2026-08-16 (milestone 3)
Section titled “v0.3.0 — 2026-08-16 (milestone 3)”The recipe engine: strict validation through the specification SDK, all
four ingredient kinds, semver resolution with per-digest differential sync,
offline cosign verification in both published layouts, source substitution
and the zone cascade, FileSet serving under /files/, tobby quickstart,
tobby recipe push, Linux packages (.deb/.rpm/.apk), and five commented
example recipes.
- Fixed defects: content and task filters only reacted to their first control (B-011), plus a batch of UI corrections (copy toasts, theme and language switches under boosted navigation, platform counts shown as present/total).
v0.2.0 — 2026-08-12 (milestone 2)
Section titled “v0.2.0 — 2026-08-12 (milestone 2)”The first complete journey behind authentication that is on by default:
bilingual server-rendered web UI, content browsing, on-demand unit import
with platform selection, persistent task tracking, the /api/v1 API with
its self-served OpenAPI document, and the TBY-* error taxonomy.
v0.1.0 — 2026-08-11 (milestone 1)
Section titled “v0.1.0 — 2026-08-11 (milestone 1)”Foundations: the application skeleton (layered configuration, structured logs, probes, metrics, graceful shutdown), the embedded OCI registry with the relocation layout, the audit journal and run identifier, the five-level quality gates, and the groundwork of the SLSA L3 release chain.
Known limitations
Section titled “Known limitations”Current limitations are documented with their consequences and justifications on limits and out-of-scope; they are tracked per feature in the status table above rather than per release.