FreeSnitch 0.3.1

A same-day fix for a defect found while verifying 0.3.0 on a real installation.

What was wrong

If your rule store contained a rule that a later validation rule rejects, the helper answered rule requests with an empty payload. Every rule disappeared from the app and from freesnitch rules list, while sitting intact in the database, and the error blamed a version mismatch that did not exist.

This affected reverse-DNS rules (.in-addr.arpa, .ip6.arpa) that earlier builds created before those names were refused as destinations. On the machine this was found on, 19 of 113 distinct rule hostnames were of that kind, and that was enough to hide all 217 rules.

Because the same encoder produces the snapshot delivered to the network extension, this could also stop policy reaching the filter, which fails open.

The fix

Bounding a payload and judging its content are now separate jobs:

• Bounds (byte size and rule count) still apply to everything crossing a process boundary. That is the protection added in 0.3.0 and it is unchanged.
• Content is judged where rules ENTER the policy: adding, updating, or importing. Reverse-DNS destinations are still refused there, exactly as before.
• Reading your own stored rules back out no longer re-judges them, so a rule accepted by an older build stays visible and manageable.
• A failure on an XPC path is now logged with its reason instead of being flattened into an empty reply.

If you installed 0.3.0 and your rules appeared to vanish, they were never lost. Update to 0.3.1 and they are all there.

Everything else

Unchanged from 0.3.0. See the 0.3.0 notes for the full feature list, safety model, and known limitations.