What is safe today, and what is not finished yet

On first run, ferry generates a self-signed certificate and private key, then stores them in the platform config directory with restrictive permissions where the OS supports them.

Peer identity is the BLAKE3 fingerprint of the certificate bytes. The trust-store types and commands exist today, and the TUI can ask before saving an unknown peer fingerprint, but the direct-address sender still accepts the presented receiver certificate without checking that store.

The direct transfer path is encrypted, but it is not yet peer-authenticated. Persistent identity, ferry peers trust, and ferry peers forget are groundwork. TUI fingerprint confirmation exists for peer-targeted sends; transfer-path enforcement is still planned protocol-hardening work.

• Print PSKs, private keys, or full trust-store contents in normal logs.
• Treat aliases or hostnames as authentication.
• Auto-accept unknown peers by default.
• Write outside the receive-side destination directory.
• Follow absolute paths, .. traversal, or Windows reserved names from a sender manifest.
• Send any telemetry. There is no phone-home.

On the receive path:

• Every manifest entry is normalized and checked before any bytes are written.
• Fresh body bytes go through a destination-local temp file and are atomically renamed on success.
• BLAKE3 of the received body is compared against the manifest before the temp file is promoted.
• Matching files skip, verified prefixes resume, and conflicting existing files fail closed rather than overwrite silently.

FileFerry is pre-1.0 and does not yet have a dedicated CVE handling pipeline. If you find a security issue, open a private security advisory at github.com/dunamismax/fileferry/security/advisories rather than a public issue.