Johnathan Corgan
6eff0accce
The directory given to `profile tick on` travelled from the control socket straight into a root create_dir_all with no validation. The socket is reachable by the fips group, which docs/reference/security.md writes down as strictly weaker than root, so a group member could create a root-owned directory anywhere on the filesystem, including a path a later privileged component reads. A privileged daemon now resolves --dir against /var/log/fips: absolute, no `..` component, and still under the root once every existing ancestor has been followed through its symlinks, so a symlinked parent cannot launder a lexically clean path. Plain canonicalize cannot do this on its own, since the directory being created does not exist yet; the resolver canonicalizes the deepest existing ancestor and re-appends the tail. An unprivileged daemon crosses no boundary and takes --dir as given, which keeps the documented non-root `cargo run` capture working. Whether the process is privileged is a parameter rather than a geteuid() call inside the resolver, so the rules are exercised without depending on the uid of whoever ran the tests, and the lifecycle tests use a start_in that takes an already-resolved directory for the same reason. The sink itself is no longer written over whatever is at its path. The name is a one-second UTC stamp and therefore predictable, so File::create would have followed a symlink pre-planted at the next name and truncated any real file it found. The file is created only if it does not exist, and a capture started in the same second as a previous one takes the next free suffix rather than failing: stop-then-start inside one second is an ordinary sequence that used to succeed by truncating. Capture files are created private to their owner and the capture directory no longer inherits a permissive umask, since a capture carries the node npub, build, platform and a timing series. Confining a root daemon to a different log root is no longer possible and cli-fipsctl.md drops that use of --dir. This affects only a --features profiling build; the subcommand is absent from a stock package.
FIPS Documentation
FIPS (Free Internetworking Peering System) is a self-organizing encrypted mesh network built on Nostr identities, capable of operating over arbitrary transports — local networks, the public internet, Tor, Bluetooth, or point-to-point links — without central infrastructure.
With FIPS, your machine becomes a node in the mesh with a self-generated cryptographic identity. There are two ways to deploy it.
As an overlay on top of existing IP networks, FIPS lets your node reach any other FIPS node wherever it sits — behind a NAT, on a different ISP, on a phone over cellular, on a laptop with only Bluetooth in range, or behind a Tor onion. The mesh forwards IPv6 traffic transparently and end-to-end encrypted, with no central VPN concentrator or coordinating server.
From the ground up over raw Ethernet, WiFi, or Bluetooth, FIPS provides a complete permissionless network without any pre-existing IP infrastructure, ISP, or DNS. Any node that joins the link gets routable IPv6 addresses, peer discovery, and a path to every other node automatically.
Either way, existing networking software runs over it unchanged: SSH, HTTP servers, file transfer, anything IPv6-native works the same way it would on a local network.
New to FIPS? Start with the Getting Started guide.
Documentation Sections
Tutorials
If you are starting from scratch and want a guided path to a working mesh, go here.
How-To Guides
If you have a specific task in mind — enabling a feature, deploying a component, diagnosing a problem — go here.
Reference
If you need to look up wire formats, configuration keys, command flags, or counter inventories, go here.
Design
If you want to understand how the mesh self-organizes, why FIPS makes the choices it does, or how the pieces fit together, go here.