CipherFS
In development · unreleased · format may change

Status and roadmap

CipherFS is unreleased. The README describes current behaviour and the requirements (Chinese) set the target; this page says what is built, what comes next and what is planned later. The order is a commitment, dates are not.

Built

  • Core: stable FileId with a causal version DAG, client-side encryption, content-defined chunking, encrypted redb index, per-device signed logs, membership and key epochs, shared history, trash and conflict views, cancellable retirement and GC, local Full/Partial content policy, plaintext export. Frozen shared format 1 with metadata schema 2 and CAS schema 1, protobuf payloads and byte-preserving authenticated records.
  • Sync: immutable Directory and S3 stores, content packs, iroh 1.3 QUIC peers with ticket-and-SAS pairing, revocation with new key epochs, recovery keys, background loops and store GC; authenticated multipart for pairing and recovery proofs, snapshots and upload inventories up to an explicit 512 MiB budget; runtime S3 credential providers (environment, static, in-memory) for Rust, C, Python and Go.
  • Owner process: one process holds a vault under an OS file lease; web login or cipherfs serve --vault publishes a private local API over a Unix socket or named pipe with a random token, and ordinary CLI commands go through the owner when the vault is busy.
  • Interfaces: CLI; FUSE mount on macOS (FUSE-T) and Linux (kernel FUSE) including the read-only conflict view; web server with Bearer sessions and the React UI; Rust SyncedVault; C, Python and Go bindings over cipherfs-api.
  • Shared management policy: causal policy resolution and periodic key-epoch rotation by an online managing device, available through CLI, HTTP and the Rust/C/Python/Go APIs.
  • Self-describing vaults: every vault carries FORMAT.md, public test vectors and the read-only reference decryptor recover.py.
  • Windows: core, API and CLI compile and pass their tests on an ARM64 virtual machine under x86 emulation; a handful of timing-sensitive tests still need a native x86 run. There is no mount on Windows.

Next: core work before release

These need no new platform or build environment and are the base for everything below.

The following format work is implemented; wire format 1 is frozen. Local schemas may continue to migrate explicitly:

  1. Vault policy record and periodic key-epoch rotation: the rotation period and the recovery notice period live in one shared policy record; any online device opens the new epoch when it is due.
  2. Lone recovery device, notice period: a device that joined with the recovery key publishes a management claim; it takes effect after the notice period (default 7 days) unless an earlier, unrevoked member objects, and an earlier member may object until it has accepted the activation. Implemented with persistent local decisions, activation barriers, late-objection replay, CLI/HTTP/bindings and unattended mode; the React UI remains frozen.
  3. Audit reservation: format 1 reserves the a/ prefix, the CFSAUD01 container and the cipherfs audit v1 label for the access audit (done in FORMAT.md).

Before the first release, without touching the format:

  1. Finishing cipherfs serve: configuration file and several vaults per daemon, readiness and health endpoints, TCP listening with TLS rules, mounts served by the owner, retiring the separate web binary.
  2. Credentials and unlock sources: file, systemd credential, keychain and remote key service providers, credential references in the store configuration, a delete-rights check for writer devices; local unlock sources, sealed state with automatic unsealing on servers, memory protections.
  3. Dioxus browser UI replacing the React UI: one component library over the HTTP API, compiled to wasm and served by cipherfs serve; React, Node and the TypeScript type generation leave the build once it matches. The React UI is frozen until then.
  4. No paths in error text or HTTP spans, so that the no-plaintext-in-logs promise holds at every log level.

Planned: server line

  • S3 front door on the daemon: SigV4, bucket and key mapping, Range reads, multipart uploads, version listing, presigned URLs, loopback by default and mandatory TLS elsewhere.
  • Server API: write durability levels, short retention policies, per-file pins and heat-based prefetch, access by FileId.
  • Access audit: a per-device file access log (device, application, time, FileId, VersionId, operation, result, bytes) stored like content: encrypted under a key derived from the epoch key, signed by the device, published as immutable objects to the stores and readable by every unrevoked member by file or by device; designed, not built. See the requirements (Chinese).
  • WebDAV store: the provider-bound transport and its contract tests exist in cipherfs-sync; registration from the CLI and web and the full acceptance run are pending.
  • Scale acceptance: a million files, 1 TB, a 100 GB file and ten devices against the scale budget (Chinese).

Planned: apps line

  • Desktop integration through the system cloud-file frameworks, macOS File Provider and Windows Cloud Files, served by the owner process; FUSE stays as the advanced mode on macOS and Linux.
  • Desktop app in Dioxus with an embedded cipherfs serve: tray, autostart, keychain and biometric unlock, browsing, preview, editing, upload and download; packaging, signing and updates for macOS, Windows and Linux; the same component library as the browser UI above.
  • Mobile: UniFFI bindings for Kotlin and Swift; Android and iOS apps that hold a Partial vault, read on demand and sync with stores from system background tasks; OneDrive, Dropbox and Google Drive stores; later Android DocumentsProvider and iOS File Provider extensions.

Not planned

  • A WinFsp driver or a WebDAV service; Windows transparent access is Cloud Files only.
  • Multi-user permissions. Every device in a vault has the same rights; subtree keys are reserved for a future read-only directory share.
  • Preserving permissions, owners, xattrs, ACLs or hard links.
  • Any trusted server. Stores and relays only ever see ciphertext.

Release

Wire format 1 is frozen. Version numbers, a changelog and the first release follow the remaining core work above; local database schemas continue to migrate explicitly. The apps and server lines ship on their own schedule against the frozen wire format.

Source file in the repository