fips/docs/releases/release-notes-v0.4.2.md

FIPS v0.4.2

Released: 2026-08-24 (provisional: the date is confirmed when the release is tagged)

v0.4.2 is a maintenance release on the v0.4.x line, and the largest one this line has carried: 144 commits since v0.4.1. Most of it is security work. It closes several paths by which a party that could merely reach a node could take its sessions down, have its traffic attributed to another node, or steer that node's path MTU; it bounds a set of tables an unauthenticated party could grow without limit; it closes the fail-open cases where a local error widened what a node accepted; it fixes NAT traversal in two places where it was simply not working; and it protects private key material on disk and clears it in memory. There is no wire format change.

The new configuration surface is small and optional: three admission and rate-limiting keys, each with a default that needs no action. The repository also gains a SECURITY.md, so someone with a finding no longer has to guess at an address or open a public issue.

v0.4.2 is wire-compatible with v0.4.1. No frame gains, loses, or resizes a field, so a mixed mesh works and nodes can be upgraded one at a time with no coordinated restart. Three changes narrow what a node accepts, or change how it acts on a field it already read: the session datagram hop limit, the path MTU floor, and routing-signal admission. Those three are what the interop gate is pointed at deliberately, rather than at connectivity alone. Compatibility is the release's intent and what that gate checks; it is not a claim that every mixed pairing was exercised.

Read the upgrade notes before you start. Two configuration shapes that loaded in v0.4.1 now refuse to start.

At a glance

Before you upgrade

• Two configuration shapes now fail to load: a node.rekey interval that fires the trigger continuously, and a traversal signal TTL too large for the replay window. Both are start-time failures, so a node carrying either will not come back after a package upgrade.
• macOS installs now read the ACL, hosts, config and identity files from /usr/local/etc/fips/, which is where the packaging puts them.

Security

• Six paths by which an unauthenticated or misattributed packet changed a node's session state are closed. One of them terminated the daemon.
• A remote party can no longer drive a destination's path MTU to zero, or aim a node's UDP punch packets at addresses of its choosing.
• Nineteen fixes harden a node against a party that can reach it but is not an admitted peer: unbounded tables, unauthenticated writes and fail-open paths. None changes the wire format and none needs action.
• Private keys are no longer written through a symlink, an existing fips.key has its mode retightened on every write, and a failed key write no longer leaves a node silently running an ephemeral identity.

Connectivity and performance

• NAT traversal works in two deployments where it did not: a public node in open mode, and any host that suspends.
• Roughly 35 ms per tick comes back at 240 peers, and multi-second rx-loop stalls during peer retry are gone.

New configuration, all optional

• node.rate_limit.session_setup_burst / _rate, node.rate_limit.established_handshake_burst / _rate, node.discovery.nostr.max_concurrent_offers_per_npub, and node.limits.max_sessions (default 1024). Each default needs no action.

Dependencies

• cargo audit reports no vulnerability, against twelve before, and every GitHub Action is pinned to a commit SHA.

A note on the security content

Most of this release is security work, and most of that work began with reviews the project did not commission. Over the past month a number of unsolicited security reviews have arrived, and they share a character: they are driven by current frontier language models, their authors say so, and they arrive as specific, carefully written reports citing the code they describe rather than as vague claims.

The findings have been legitimate. Not every one survived a second reading, and several described documented behaviour as a defect. But enough held up under adversarial re-reading that treating this class of report as noise would have been a mistake, and a substantial part of what this release fixes was found that way, including issues in code that had been reviewed before.

None of it has been reported active in a deployment. What these reviews have produced are reachable defects rather than observed incidents, and finding them at that stage is the outcome everyone would choose.

This looks like a broader shift rather than something particular to this project. The cost of a competent first pass over an unfamiliar codebase has fallen sharply, and open source is benefiting from it: small projects are now getting the kind of attention that was previously reserved for large ones. We welcome it, and we would rather receive a report of this kind than not. SECURITY.md describes how to send one. The most useful reports are the ones that say plainly which parts were machine-generated and which were verified by a person, because that is the difference between a lead and a finding, and we assess the two differently.

Behavior changes worth flagging

The session datagram hop limit now follows IP semantics

Delivery to the addressed node is no longer gated on the hop limit, and a forwarder decrements before deciding rather than after. Two cases change on a deployed line:

Case	v0.4.1	v0.4.2
Addressed to this node, hop limit 0	dropped	delivered
Transit datagram, hop limit 1	forwarded at 0	dropped here

The reachable radius is unchanged, because the two behaviors compensate exactly: a path of h links still delivers for any source hop limit of h or more. During a rolling upgrade no version mix delivers less far, and an unupgraded forwarder feeding an upgraded destination delivers one hop further than either version does on its own.

What an operator will see move is the counter. TtlExhausted now charges at the node that makes the decision rather than at the hop after it, so its distribution across a mixed mesh shifts by one hop while the upgrade is in progress. That is expected and is not a loss of traffic.

node.rekey.enabled governs periodic rekey only

This is a correction to what the setting has always meant rather than a new field. enabled controls whether this node initiates periodic rekey. A rekey a peer drives is still answered when it is off, and two things that used to sit behind the same gate no longer do: the session drain sweep and the cut-over that retires an old key epoch now run either way. A node with rekey disabled previously held superseded keys for the life of the session.

New admission defaults you may feel

None of these needs configuration, and none changes an existing key's value. They are new bounds where there was none.

• node.discovery.nostr.max_concurrent_offers_per_npub defaults to 4. It sits inside max_concurrent_incoming_offers (16), which remains the outer bound, so a value above that is inert.
• node.rate_limit.session_setup_burst (64) and session_setup_rate (16.0) meter inbound FSP session setup per authenticated link peer. A legitimate peer arriving over the same link as a flooding one shares that link's bucket, so establishment behind a flooded neighbour is refused until it refills.
• node.rate_limit.established_handshake_burst and _rate are optional and normally omitted; the bucket is then derived from node.limits.max_peers, node.rekey.after_secs and node.rate_limit.handshake_max_resends, so raising the peer limit sizes it automatically.
• An accepted inbound TCP or onion connection now has a deadline for its first frame. This is a module constant, not a configuration key.
• A remote-supplied path MTU below an actionable minimum is ignored rather than applied or stored. Locally derived MTUs are exempt at both the seed and the TCP MSS clamp, so a genuinely narrow link, which the mesh does use, still adapts.

Control socket snapshots carry new fields

show_routing and show_status gained counters this cycle: warm_malformed_packets and warm_malformed_bytes, and the four error-signal counters unbound_coords, unbound_broken, unbound_mtu and unbound_forged. An older fipsctl or fipstop reading a newer daemon gains unknown fields rather than losing known ones. If you scrape those snapshots, expect additions, not removals. Two other new counters, the framing payload_len_mismatch and the setup-message refusal counters, are not yet readable over the control socket.

The bloom announce sweep changes where its cost sits

Peer bloom filters are now computed for every recipient in one union sweep instead of being rebuilt per recipient. The result is exactly equal, not approximately: merging is a bytewise OR. The trade-off, measured rather than assumed, is that the sweep does its full work regardless of how many peers are ready, so a tick announcing to one or two peers costs about twice what it did. Break-even is around three ready peers, so a small mesh pays slightly more and a large one pays a great deal less. Cadence, the debounce, the sequence rule and the fill-ratio cap are unchanged.

Notable bug fixes

Every item here is a fix for a defect that shipped in v0.4.1. Fixes for defects introduced and resolved inside this cycle are in the CHANGELOG and are not repeated here. The CHANGELOG is the complete record; this section is a selection.

Session and handshake authentication

This is the release's centre of gravity. Six paths are closed, each of which let a packet that authenticated nothing change a node's session state.

• A truncated inner payload terminated the daemon. A SessionDatagram whose inner FSP payload was 4 to 11 bytes, with phase 0x0 and the Coords Present flag set, indexed past the end of a slice on the coordinate-cache warm path. The receive loop is the process's main future, so the panic took the daemon down rather than a task, and under the packaged systemd unit the node restarted into the same frame. Any peer past a link handshake could send it, and admission is default-open.
• An unauthenticated setup message could hold a session down. With node.rekey.enabled false, a setup message naming an established peer replaced that peer's session outright, discarding the live keys. The message carries no authenticator and its source address is an envelope field the sender picks. The established case now arms a handshake beside the running session and adopts new keys only after a msg3 whose authenticated static key matches the one the session was opened with.
• A forged SessionAck cancelled an in-flight initiation, and an unauthenticated msg3 discarded a completed key epoch. Both took 57 bytes of the right length from anyone who could reach the node, and both were repeatable. The setup path is now also rate limited, keyed on the authenticated link peer the datagram arrived over rather than on the address the sender claims.
• A peer could complete a genuine handshake under another node's address. The responder recorded a session under the source address in the datagram without checking it against the static key it had just authenticated, so the identity cache, the session map and the reconstructed mesh IPv6 all attributed that traffic to the node it named. The address is now derived from the authenticated key, on both the initial and the rekey path.
• Routing signals were acted on for any address. CoordsRequired, PathBroken and MtuExceeded carry no end-to-end authentication, and a node applied their effects for any destination they named. They are now refused unless this node has itself bound that destination, and each refusal is counted. Signals from a genuine on-path forwarder at any distance are unaffected.
• The established-address waiver admitted the wrong party. A transport with accept_connections false still admits an inbound msg1 sourced from an established peer's address, so a peer re-handshaking after a restart is not locked out. Nothing checked that the sender was that peer, so any off-path party sourcing from the address obtained a full link handshake from a node configured to accept none. The handshake is now dropped once the key exchange reveals a static key that does not belong to the identity owning that address.

A frame whose declared payload length disagrees with the length that arrived is also now dropped at the single dispatch point, before that field can be used as a parsing input. This closes no known defect: on the stream transports the comparison holds by construction, and on the datagram transports a short frame already failed the AEAD tag. What changes is which reason it is dropped for.

NAT traversal and Nostr discovery

• Traversal was non-functional on a public node in open mode. A signal is addressed to the merge of the peer's inbox relays, the relays its advert nominates, and our own, but the send was rejected outright if any single URL in that merge was outside the client pool built at startup. One unconfigured relay killed the whole attempt, including the sends to relays both sides shared. Measured in an open-mode window: 309 attempts, 290 explicit failures, zero successes, every failure on relay not found. Configured peers were unaffected, since they run a matching relay set. Comparison is now on the normalized relay URL, so a trailing slash or a different host case does not discard a relay that is in fact configured.
• Traversal broke permanently after the host suspended. The traversal clock cached a Unix timestamp at startup and advanced it with a monotonic instant, which does not tick while a machine is asleep, so the daemon's idea of the time trailed real time by the suspend duration for the rest of the process lifetime. Every expiration it published was already in the past, relays dropped the offers, and traversal stayed dead until restart. The clock now reads the wall clock on every call. A laptop is where this is easiest to hit, but any host that suspends or hibernates was affected. Reported in #128.
• A node could be aimed at third parties. A rendezvous-enabled node punched every address a signed offer named, with no limit on how many one offer could carry, so any npub could have it emit a burst of UDP packets carrying its own source address at loopback, link-local, multicast, broadcast, unspecified or CGNAT addresses. Never-routable ranges are now rejected, IPv4-mapped forms are canonicalized first so they cannot slip past, port 0 is dropped, private-range candidates are punched only when they share a /24 with one of our own addresses, and the planned list is capped at eight. Each planning attempt logs what it declined and why.
• A future-dated traversal signal was accepted as strictly fresh. The freshness check measured age with a saturating subtraction, which yields zero for any timestamp ahead of the local clock, and nothing else bounded the issue time from above. Forward-dating is now tolerated only to the same 60s of clock skew already allowed in the other direction, and a declared expiry is no longer trusted past the issue time plus the configured TTL.
• One sender could hold every inbound offer slot. Admission took a permit from a single pool before any identity check, with the sender's npub used only as a log field. Admission now takes a per-npub permit and a global permit together. This does not make the pool inexhaustible: Nostr identities cost nothing to generate, so four throwaway npubs still saturate the shipped 16-slot pool at an unchanged total offer rate. What it buys is that one identity can no longer do it alone, and that the two refusals are distinguishable in the log.

Path MTU

A single MtuExceeded carrying a very small value drove a session's path MTU to zero, after which every packet to that destination was answered with an ICMPv6 Packet Too Big instead of being sent: a blackhole lasting until the daemon restarted. The same value reached the SYN-time TCP MSS clamp, where anything at or below 137 saturates the segment size to zero. The path_mtu field is an unsigned per-hop annotation carried outside the signed proof, and MtuExceeded and PathBroken arrive unencrypted with no sender check, so any forwarder, or anyone able to reach the node, could lower it.

Remote values below an actionable minimum are now ignored at the three places a remote value is acted on, each with its own warning and counter, and the per-destination cache has a way back: an entry is released on a PathBroken report, on session idle expiry, and on handshake timeout, with the local link MTU reseeded in its place. Entries written by the discovery lookup carrier age out on a deadline of their own, because a destination this node never opens a session with reaches none of those three routes. Without it, one response carrying a floor value pinned that destination's clamp until the daemon restarted.

Inbound connection slots and rekey admission

• An unauthenticated remote could lock out inbound peering by staying silent. The peer cap was tested at accept, with no read in between, and the frame reader's reads carried no deadline. Pool keys are ip:port, so N sockets from one address took N slots, and at the 256 default that closed the node to new peers for as long as the sockets stayed open. The first frame now has a deadline, the onion listener gets the same treatment, and the handshake reaper now closes the transport connection it used to forget. This does not close the whole case: a peer that sends one well-formed frame and then goes silent still holds its slot.
• Rekey traffic was being refused on busy nodes, silently. Rekey and restart msg1 on an established link competed with stranger admission for one shared token bucket. Measured on a field node at roughly 245 peers: 8753 msg1 refused in 25 minutes, with 159 of the 201 distinct sources being peers it already held sessions with. Nothing errored and no session dropped, so the only symptom was a flat rekey_armed. Inbound msg1 is now classified before it is limited and draws on its own bucket. Nodes upgrade with no config change, and the Msg1 rate limited line now says which limb refused.

Identity and key files on disk

• A private key write followed a symlink, because the single write path opened with create and truncate and no O_NOFOLLOW. Both writers now share an open helper that carries it.
• An existing fips.key kept a loose mode forever. The mode was supplied only through open(2), which the kernel honours on creation and ignores otherwise, so a key file at 0644 stayed 0644 through every rewrite. That needs no attacker: one chmod, or a restore that did not preserve modes, leaves the key readable indefinitely. The mode is now applied to the open descriptor before any secret bytes are written. On Windows neither protection applies and the file inherits the parent directory's ACLs; that exclusion is deliberate.
• A failed key write left a node running an ephemeral identity in silence. Six write results in the identity path were discarded, and the sharpest was in persistent mode: a failed write to fips.key fell through to an ephemeral identity with no message, so a node asked for a stable identity changed its npub, its routing address and its mesh IPv6 on every start, and nothing said so. All six now report.
• Key material is now cleared when it goes out of scope. Nothing in the crate erased a key before this. Clearing now covers the session and handshake keys, the identity keypair, the temporary copies the elliptic-curve operations make, encoded secrets, and the private key on its way through configuration, including the config file's text, since node.identity.nsec is read straight out of it. This clears the copies the crate owns, not every copy that ever existed: the secp256k1 key types are copyable, and the hash, key-derivation and cached cipher states of the pinned libraries offer no clearing route. Reading the residue needs access to the process's memory, or to a core dump or swap image of it. This carries a source-breaking change for library consumers; see the upgrade notes.

Gateway DNS answers

The gateway's DNS forwarder accepted whatever datagram arrived on its upstream socket. The upstream query reused the client's own transaction ID, the socket was wildcard-bound and never connected, the receive discarded the sender, neither the response ID nor the question was compared against what was asked, and the returned address was not checked against the mesh prefix. Because the extracted address is installed as a DNAT rule with no interface constraint, a forged answer redirected traffic rather than only poisoning a lookup.

The query now carries a random transaction ID, the socket is connected so the kernel drops foreign sources, a response must match on ID, question and type, and the address goes through the validating parser before any allocation. One deliberate behaviour change: validation sits before the rcode check, so an upstream answering FORMERR or REFUSED with an empty question section now yields SERVFAIL rather than having its rcode relayed. Checking after the rcode would admit a forged NXDOMAIN.

macOS install layout

On macOS the daemon and fipsctl read /etc/fips/, a directory the macOS packaging does not create, while the packaging installs to /usr/local/etc/fips/. The effect was silent in the worst way: a populated peers.deny reported effective_mode: "default_open" with enforcement_active: false through fipsctl acl show, host-file aliases went unloaded, and fipsctl keygen wrote an identity where the daemon never read it, so the node kept an ephemeral one. The default paths now follow the platform's packaging, the system config search path includes /usr/local/etc/fips/fips.yaml, and a key stranded at the legacy path is adopted with a warning rather than a fresh identity being generated. Linux and Windows behavior is unchanged.

macOS users with existing files in /etc/fips/ should move them to /usr/local/etc/fips/.

Robustness under adverse local conditions

• A failed log write could panic the thread or task that logged. The subscriber reported its own internal errors through eprintln!, which panics when stderr has also failed, and the shipped supervisor configurations make that one condition rather than two: the macOS plist points both standard streams at one file, and the systemd units route both to journald, so one full disk fails both sinks together. In the daemon the casualty was a crypto worker, which takes its share of the peer space with it permanently. In fips-gateway it was a spawned task: the DNS resolver, the control accept loop or the pool tick, none of which is observed until shutdown, so the process kept running and reporting healthy with mesh name resolution or lease expiry and NAT cleanup stopped.
• Flap dampening could engage only once in a node's lifetime. The arming check tested whether a deadline had ever been set rather than whether one was still in effect, so after the first episode a node in a second flap storm went on switching parents under hold-down alone, and neither the flap_dampened counter nor the warning fired again. Hold-down was unaffected throughout, which is why the practical cost at shipped settings was lost visibility rather than unrestrained flapping. Separately, a node.tree.flap_dampening_secs large enough to overflow the monotonic clock is now capped at one year instead of panicking the node when dampening engages.

Supply chain

• The dependency lockfile moves past a set of advisories against the pinned nostr 0.44.3 and nostr-relay-pool 0.44.1, both of which were also yanked. The ones that matter here are the relay-pool advisories describing forged events bypassing signature validation and unverified relay events being processed: that is the path a node learns peer adverts on, and it performs no independent verification of its own, so the exposure was a misattributed advert rather than the denial of service the summaries lead with. cargo audit now reports no vulnerability, against twelve before. Four warnings remain that no version move fixes.
• Every GitHub Action reference is now pinned to a commit SHA. None of the sixty-six was pinned before, including the jobs holding the AUR deploy key, the jobs with release write scope, and the packaging jobs that run with a signing key in the environment. Sixty-two are full SHAs; four are justified in one place, since two actions read the tool to install from the ref name itself. The sharper hole was not the tags: the OpenWrt workflow fetched a helper binary and a toolchain from release URLs with no verification at all, in two jobs holding a signing key. Both downloads now check a per-architecture pinned SHA-256.

Limits, provenance checks and fail-closed defaults

Nineteen fixes harden a node against a party that can reach it but has not been admitted to it. Every claim behind them was assessed and then re-read by a separate reviewer briefed to refute it, and only what survived that pass is here. None changes the wire format, and none needs configuration.

They fall into four shapes.

Tables that an unauthenticated party could grow. The established session table had no population cap and now defaults to 1024, tunable with node.limits.max_sessions. The UDP transport's DNS cache grew one entry per hostname ever dialed and is now bounded at 256 with eviction. The Ethernet discovery buffer deduplicated beacons with a full scan and had no cap; it is now a map bounded at 1024 distinct MACs. The lookup dedup cache was fail-closed at its bound, so a flood stopped every lookup transiting the node; it now evicts instead of refusing.

State an unauthenticated packet could change. A relay-returned Nostr advert was cached without checking that the peer it named had signed it. A lookup response was acted on with no correlation against a lookup this node had issued. A STUN binding response was accepted from any source. A NAT punch packet was accepted from any address whose digest matched. Each now checks the thing that binds it.

Denial paths reachable from off the path. An epoch-mismatch msg1 is authentic but replayable, and accepting it tore down a working peering; it is now refused while that peering is still carrying authenticated traffic, and dampened against repetition. The routing-error limiter was keyed on the field the attacker chooses. The Nostr notify loop ran two decrypts and a signature verify per event ahead of any limiter. A retired FSP key epoch could be held resident indefinitely by a peer that kept using it.

Local fail-open surfaces. A read error on peers.allow or peers.deny was swallowed and published an empty ACL, which took a strict allowlist node to admitting everyone; the last good policy is now held and retried. The control socket and its parent directory were created under the ambient umask and only tightened afterwards. The DNS mesh-interface filter was keyed on the configured TUN name and so had never run on macOS or FreeBSD.

Some findings from the same review pass are not addressed here. Where a fix requires a wire-format change it is not a candidate for the 0.4.x line at all, which takes none; that work belongs to a later release. SECURITY.md sets out the trust model this protocol assumes, and it is worth reading if you are deciding how far to rely on a mesh whose membership you do not control.

Two portability defects are fixed alongside them: a Windows build failure and a set of Windows and macOS unit-test failures. Both were caught by CI on those platforms rather than by review, and the coverage gap that let them through is recorded at the sites.

A documented claim that was wrong

The security reference named both Noise patterns unqualified, which told anyone auditing the stack against the Noise specification that the construction was standard. It is not, in one respect: the handshake AEAD passes an empty associated-data field where standard Noise EncryptAndHash uses the handshake hash. Domain separation and Diffie-Hellman binding survive through the chaining key; transcript binding is the property actually absent. Nothing in the daemon reads the handshake hash, so no shipped behaviour rests on it, but anything later built on it (channel binding, an exporter, cookie binding) would silently not work. The reference now says so.

Upgrade notes

There is no wire format change and no coordinated restart. Nodes can be upgraded one at a time in any order. One thing must be done before you upgrade, not after, because it is a start-time failure rather than a degradation.

Check two configuration relations before upgrading

Two configuration shapes that loaded in v0.4.1 are now rejected at config validation. A node carrying either will not start after the package upgrade. Both were settings that looked like they disabled something and in fact made it fire continuously, so a rejection is the correct behaviour, but it arrives at the least convenient moment if you meet it for the first time on a restart.

Check your config file before you upgrade:

grep -nE 'after_messages|after_secs|signal_ttl_secs|replay_window_secs' \
  /etc/fips/fips.yaml

On macOS the file is at /usr/local/etc/fips/fips.yaml.

1. node.rekey.after_messages must be at least 1. Zero makes the message-count arm true on every poll, because the trigger compares with greater-or-equal, so a node rekeyed on sight rather than never. The default is 65536. If you set it to 0 intending to disable the arm, use a very large value instead; there is no upper bound.

2. node.rekey.after_secs must be greater than 15, the per-session rekey jitter. Each session offsets the interval by a random value within plus or minus that bound, so a smaller interval saturates to zero on a negative draw and rekeys on sight for roughly half of sessions. The default is 120. Both rekey checks run whether or not node.rekey.enabled is true, so turning rekey on later cannot surface the error at a surprising moment.

3. node.discovery.nostr.signal_ttl_secs plus 120 must be less than node.discovery.nostr.replay_window_secs. A traversal signal is acceptable over its TTL plus 60s of clock-skew grace on each side, and that span has to stay strictly inside the replay window, or a session id evicted from the replay cache on expiry is still fresh enough to be accepted a second time. The relation was documented but unenforced, so raising the TTL past 180s silently voided it. The shipped defaults, a TTL of 120 against a window of 300, are unaffected. The error names the concrete floor for replay_window_secs, so if you hit it on a test start the fix is in the message.

The safest sequence is to run that grep on every node's config first, correct anything that trips one of the three rules, and only then upgrade.

If you use fips as a library

Binaries are unaffected. Skip this section unless you build against the fips crate.

Four public types gained a Drop implementation as part of clearing key material at end of scope: Identity, ResolvedIdentity, IdentityConfig and HandshakeState. A type that implements Drop cannot have its fields moved out, so this is source-breaking for a consumer of the library crate even though nothing about the shipped binaries changes.

IdentityConfig is the one most likely to be reached in practice, because it hangs off the public Config as node.identity. Code that moved the nsec out of a configuration value no longer compiles. The fix is Option::take on the field rather than moving the value out.

This is a source break in a patch release, which semantic versioning does not sanction. It ships anyway because the alternative was holding a security fix for the next minor, and because the crate is not published to a registry, so the reachable population is small.

During and after a rolling upgrade

• TtlExhausted charges at a different node than it did, so its distribution shifts by one hop while the mesh is mixed. This settles once every node reports 0.4.2.
• If you scrape the control socket, expect show_routing and show_status to carry new counters. An older fipsctl or fipstop gains unknown fields rather than losing known ones.
• On macOS, move peers.allow, peers.deny, hosts, fips.yaml and fips.key from /etc/fips/ to /usr/local/etc/fips/. The daemon warns once at startup if it finds any of them only at the old location, and it will adopt a key stranded there rather than generating a new identity, but the warning is the signal to move them rather than to leave them.
• A mesh whose peers advertise a legitimately narrow path MTU should be watched once after the upgrade. Locally derived values are exempt from the new floor at both the seed and the clamp, so a narrow link is expected to adapt as before, but that exemption is asserted in the code rather than proven by a test that drives a genuinely narrow path.

Downgrading to v0.4.1 is supported. A config corrected for the three rules above still loads on v0.4.1, so the correction does not have to be reverted.

Getting v0.4.2

• Linux x86_64 / aarch64: .deb and tarball at the v0.4.2 release page.
• Arch Linux: fips from the AUR.
• macOS: .pkg at the v0.4.2 release page.
• Windows: ZIP at the v0.4.2 release page.
• OpenWrt: .ipk (OpenWrt 24.x and earlier) or .apk (OpenWrt 25+) at the v0.4.2 release page.
• From source: cargo build --release from a checkout of the v0.4.2 tag (Rust 1.94.1 per rust-toolchain.toml; libclang-dev is a required Linux build prerequisite).
• Nix / NixOS: nix build .#fips from a checkout of the v0.4.2 tag builds the binaries from source with the pinned toolchain and no manual prerequisites (see the Nix section of packaging/README.md).

The full per-commit changelog lives in CHANGELOG.md. Issues and discussion at github.com/jmcorgan/fips.

Security reports have a private channel as of this release; see SECURITY.md.

Contributors

Thanks to everyone who contributed code, packaging work, bug reports, or reviews to this release.

• @jmcorgan (Johnathan Corgan): release shepherd; the session and handshake authentication work, path MTU bounding, key material protection and clearing, gateway DNS answer validation, Action pinning and the dependency refresh, the traversal clock fix, spanning-tree and rate-limiting work, and the test harness.
• @sh1ftred: the macOS install layout fix, so config, ACL and identity paths follow the platform packaging (#132). First contribution to FIPS.

Bug reports and reviews that shaped this release:

• @Theleifless: reported #128, NAT traversal breaking after the host sleeps.
• @ngmisl: filed #137, the security review most of this release's security work answers.