v2.33.1 — accepted here, dropped there

v2.33.1

Three fixes, and each is something the library accepted in one place and quietly failed on in another.

A redirect rule that the firewall enforces made firewall-check report an internal error. A start-end range that an IpAddress rule honours matched nobody on the lockdown allowlist. And the lockdown flag that the firewall obeys was invisible to both firewall-check and firewall-doctor, which only knew the mode: lockdown shorthand.

PHP 8.1–8.5 supported. No new configuration keys, and no configuration changes are required.

What changes on upgrade

• firewall-check has a new exit code, 3, for a redirect. A request matching a response: redirect rule used to exit 70 (internal error), so nothing that worked before behaves differently. A script that treats every non-zero exit as "blocked" will now also treat a redirect as blocked. --json gains a location key, null unless the verdict is redirected.
• A start-end range in global.lockdown_allow now matches what it says. Before, it matched nobody. An allowlist that was locking out its own office starts serving it.
• firewall-doctor can now report a lockdown finding as an error on a config it used to pass. That happens when lockdown is on and an allowlist entry can never match. Doctor exits 1 on an error, so a deploy gate that runs it can turn red. Every such config was refusing visitors it named.
• firewall-check with lockdown: true reports the rules' verdict, not the lockdown's. Every request used to come back BLOCKED (503). It now says what the rules decide, with the lockdown noted beside it.

Fixed

• firewall-check exited 70 on a matching response: redirect rule (#406, #408). FirewallRedirectException (2.26) was not caught, so it fell through to the catch-all: "evaluation threw unexpectedly". A CI gate asserting that a redirect rule works could not pass. It is now its own verdict, REDIRECTED, exit 3, with the target and status in the output:

  REDIRECTED  GET /old-admin
    client            1.1.1.1
    redirected by     Old admin
    status            301
    location          https://example.com/notice

• The lockdown allowlist silently ignored start-end ranges (#407, #410). passesLockdown() validated entries as an address or a CIDR block only, so 203.0.113.10-203.0.113.20 matched nobody, with no error at startup and no log line. Lockdown now accepts an address, a CIDR block or a range, IPv4 and IPv6, bounds inclusive. A range written backwards (.20-.10) or mixing families is refused rather than guessed at. Storage queries (firewall-block un-block ranges and the rest) are unchanged.

  firewall-doctor had counted such an entry as coverage, reporting ✓ Lockdown allowlist has 1 entry for a list that served nobody. It now names every entry that can never match, as an error while lockdown is on and a warning otherwise:

    ✗ Lockdown is ACTIVE and its allowlist has 1 entry that can never match
        "203.0.113.20-203.0.113.10" is not an address, a CIDR block or a start-end range, so it serves nobody.

• lockdown: true was not recognised by the diagnostic tools (#407, #409, #411). It is the only way a mode: exception host can lock down. firewall-doctor reported a site in lockdown through the flag as "Not currently in lockdown". firewall-check set lockdown aside for the check only when the shorthand was used, so with the flag every request came back BLOCKED by the lockdown itself, the rule that would match was never named, and the lockdown ACTIVE note was never printed. Both tools now treat the flag and the shorthand the same.

Full changelog: v2.33.0...v2.33.1