Handle missing bootstrap progress parsing

SECURITY_REVIEW.md

@@ -0,0 +1,27 @@
+# Security Review of Python Scripts
+
+## Summary
+This review evaluates the Python scripts under `usr/libexec/helper-scripts` and related packages for security concerns. The primary issues center on unbounded network traffic generation and missing input validation that could lead to denial-of-service conditions or unintended network scanning. These behaviors are currently intentional test utilities rather than exploitable vulnerabilities, but they can still be dangerous when used without safeguards.
+
+## Findings
+
+### Unbounded network scanning in leak test scripts
+* Files: `usr/libexec/helper-scripts/leak-tests/tcp_test.py`, `usr/libexec/helper-scripts/leak-tests/udp_test.py`, `usr/libexec/helper-scripts/leak-tests/exhaustive_ip_send.py`
+* Severity: High (could trigger abuse reports, firewall blocks, or DoS on target networks)
+* Details: These scripts send packets to `scanme.nmap.org` across **all** ports or protocol numbers without throttling or consent. Running them accidentally on a networked host could overwhelm the target or draw unwanted attention. The scripts also import `scapy` with `import *`, making code harder to audit and raising the risk of namespace collisions. While the traffic generation is part of the intended leak testing workflow, the lack of operator confirmation makes accidental misuse more likely.
+* Recommendations: Add explicit rate limiting, target allow-list confirmation, and a mandatory interactive prompt that describes the traffic volume. Replace `import *` with explicit imports to reduce unexpected behaviors. Document the intended usage to clarify that high-volume traffic is expected only in controlled environments.
+
+### Lack of response handling in `simple_ping.py`
+* File: `usr/libexec/helper-scripts/leak-tests/simple_ping.py`
+* Severity: Medium (runtime crash risk)
+* Details: The script checks `isinstance(test_ping, types.NoneType)` but never imports `types`, which will raise a `NameError`. That failure can mask actual network reachability results and could cause automated leak tests to misreport status. The crash stems from the current coding style rather than an underlying library bug.
+* Recommendations: Import `types` or, preferably, compare against `None` directly (e.g., `if test_ping is None:`) and handle exceptions from `sr1` to avoid crashes.
+
+### Robustness of Tor bootstrap scripts
+* Files: `usr/libexec/helper-scripts/tor_bootstrap_check.py`, `tor_consensus_valid-after.py`, `tor_consensus_valid-until.py`
+* Severity: Low (graceful failure, potential unhandled exceptions)
+* Details: Scripts assume `stem.connect()` succeeds and that controller queries always return valid values. If Tor is unreachable, they may exit with unclear codes or raise exceptions when parsing bootstrap progress (e.g., `re.match` without a None check).
+* Recommendations: Validate connections, wrap controller queries in try/except, and provide clear exit codes and messages when Tor is unavailable.
+
+## Conclusion
+The most critical issues are the aggressive traffic generation in the leak test scripts, which should be mitigated with explicit safeguards before any production or automated use. Minor robustness improvements are recommended for the remaining scripts to prevent misleading results during failure scenarios.

TEST_RESULTS.md

@@ -0,0 +1,13 @@
+# Test Run Report
+
+Command: ./run-tests
+
+Date: 2025-12-02 04:58:15Z
+
+Result: Failed (10 failures, 12 passed)
+
+Notes:
+- Failing cases are primarily in stdisplay utilities (stcat, stcatn, stecho, stprint, stsponge, sttee).
+- Failures include unexpected ANSI escape sequences that were not sanitized and missing terminfo entries (xterm-direct, xterm-old).
+- Terminfo lookup gaps suggest an environment/configuration issue rather than a product bug; rerun after installing the required entries to confirm.
+- See test log in the run output for full details.

usr/libexec/helper-scripts/tor_bootstrap_check.py

@@ -28,7 +28,11 @@
 
 print(format(bootstrap_status))
 
-progress_percent = re.match('.* PROGRESS=([0-9]+).*', bootstrap_status)
+progress_percent = re.search(r"PROGRESS=([0-9]+)", bootstrap_status)
+
+if not progress_percent:
+    controller.close()
+    sys.exit(255)
 
 exit_code = int(progress_percent.group(1))