~ober/jerboa-fuse

Imported from ~/mine/jerboa-fuse

download snapshot

about

# jerboa-fuse

Experimental FUSE filesystem bindings, memory-backed filesystems, and encrypted-vault helpers for Jerboa.

The repository contains Jerboa modules for building FUSE filesystems, an in-memory test filesystem, secure-memory helpers, access-control helpers, vault-oriented examples, and a small native mount helper.

## Status

Private/experimental Lane C. Do not treat this repository as production-ready until the filesystem threat model, deployment hardening policy, FFI boundary documentation, vault recovery behavior, and native dependency review are complete.

The current code is intended for local development and review. It is not ready for unattended mounts, privileged deployment, or use with irreplaceable data.

## Build

```sh
make build
```

The build compiles `src/mount_helper.c`, which owns FUSE mount calls, secure memory helpers, blockstore file I/O, and OpenSSL-backed vault crypto wrappers.

## Test

```sh
make test
make audit
make security
make sbom
make openssl-advisory-check
make reproducibility-report
make target-evidence
make release-evidence
```

`make test` runs memfs, secure-memory, access-controller, and vault tests. It does not perform a real FUSE mount in CI; mount smoke tests require an explicit Linux/FreeBSD host with FUSE configured.

`make release-evidence` records the local release artifact bundle under `dist/release-evidence/`, including toolchain identity, native linkage, an SBOM/platform-support bundle, deployment privilege policy markers, an OpenSSL advisory gate, source inputs, hashes, and a two-clean-build reproducibility report. Production candidates must link a patched OpenSSL line: 4.0.1+, 3.6.3+, 3.5.7+, 3.4.6+, or 3.0.21+.

Production support is blocked until `make target-evidence` records marker-
complete target mount, vault corruption/recovery, and service-sandbox proof
files through `JERBOA_FUSE_TARGET_MOUNT_PROOF_FILE`,
`JERBOA_FUSE_TARGET_CORRUPTION_PROOF_FILE`, and
`JERBOA_FUSE_TARGET_SANDBOX_PROOF_FILE`, or equivalent release-host evidence is
attached. Proof files must not contain vault contents, passphrases, keys,
private paths, hostnames, raw mount output, or raw command output.

## Security

Filesystem code can expose or corrupt local data if path, mount, permission, or lifecycle handling is wrong. Review [SECURITY.md](SECURITY.md), [docs/threat-model.md](docs/threat-model.md), [docs/deployment-hardening.md](docs/deployment-hardening.md), [docs/ffi-boundary.md](docs/ffi-boundary.md), and [docs/release-evidence.md](docs/release-evidence.md) before using it outside tests.

recent commits