Parse GITLAWB_ICAPTCHA_INSECURE value so =0/=false disables the loopback relaxation #227

is_https in crates/icaptcha-client/src/lib.rs:98 gates its http-loopback trust relaxation on std::env::var_os("GITLAWB_ICAPTCHA_INSECURE").is_some(), a presence check. An operator who sets GITLAWB_ICAPTCHA_INSECURE=0 or =false intending to disable it still enables the branch: only fully unsetting the variable disables it. Verified against a standalone build: =0, =false, and empty all yield is_some() == true; only unset yields false.

The insecure branch is release-reachable (not #[cfg(test)]-gated): is_https is called on the live path from resolve_solver_url (lib.rs:136, :154).

Blast radius is bounded, so this is a low-severity footgun, not an exploit. resolve_solver_url still contains a node-advertised loopback URL by two independent gates: the host-allowlist (allowed(origin_key(a)) at :154, which admits only the default https://icaptcha.gitlawb.com or the operator's configured GITLAWB_ICAPTCHA_URL origin) and the operator-origin key binding (:166, the bearer token is attached only when the resolved origin equals the operator origin). So setting the flag alone has no exploitable effect unless the operator also points GITLAWB_ICAPTCHA_URL at a loopback origin.

Repro: run any cfg(test)-off caller with GITLAWB_ICAPTCHA_INSECURE=0 and observe is_https("http://127.0.0.1") returns true.

Fix direction: parse the value and treat only an explicit truthy set ("1"/"true") as enabled, logging when a non-empty non-truthy value is seen; or drop the runtime env flag entirely in favor of a test/example-only injection seam so nothing insecure ships in the release binary.

Notes: this line is pre-existing main code (commit ad7c2b2, PR #168), not introduced by any open PR. Filing so the value-parse hardening itself has a public tracker; low severity, close if it's not worth pursuing.