Repository navigation
fix(ci): make canary image verification resilient against transient Tor TLS and network resets - #8
Conversation
…or TLS and network resets (#7)
🛡️ QA Test & Verification Report (Quality Gate 1 - ADR-005)Target PR: #8: fix/canary-verification-resilience 1. CI / Pipeline VerificationThe pre-merge CI validation pipeline ran against head commit
2. Blackbox & Edge-Case Audit (ADR-005)A thorough blackbox and edge-case assessment was performed on the hardened
3. Conclusion & Gatekeeper HandoverAll tests, blackbox edge cases, and CI workflows have passed without defects or regressions. |
hapheus
left a comment
There was a problem hiding this comment.
🛡️ Senior Code Review & Gate 2 Gatekeeper Sign-Off (ADR-006)
PR: #8 (fix/canary-verification-resilience)
Commit: 27c326f763df2804485735c63c185c10836ab6b1
Reviewer: Senior Code Reviewer & Gatekeeper
Verdict: APPROVED (Ready to Merge)
1. Architectural & Standards Compliance (ADR-001 – ADR-010)
- ADR-003 (SOLID / SRP): The workflow strictly adheres to single responsibility. Separation of container runtime verification, network egress checks, failure diagnostics, and notification lifecycle is cleanly orchestrated.
- ADR-006 (Code Review Gate): Exhaustive pre-merge audit conducted across workflow structure, error branches, and security parameters.
- ADR-010 (Minimal Dependencies): Utilizes standard runner CLI tools (
curl,jq,docker,actions/github-script@v7) without adding extraneous external action dependencies.
2. Resilience, Error Handling & Edge Cases
- Exit Node & TLS Flapping Defense: Integrated 3-attempt outer loop with internal
curl --retry 2 --retry-all-errorscovering transient TLS/handshake drops (curl exit code 35). - Fallback Egress Verification: If
check.torproject.orgexperiences transient disruption or rate-limiting, the workflow reliably queriesapi.ipify.orgwhile strictly verifying that egress does not matchRUNNER_IP(leak-prevention guarantee). - Circuit Stabilization: 5-second sleep following Tor bootstrap prevents racing against initial circuit assembly.
- Diagnostic Observability: Container logs (
docker logs torproxy-canary) are dumped automatically on step failure (if: failure()). - Issue Lifecycle Automation: Auto-closes open
canary-alertissues upon consecutive successful runs.
3. Security & Permissions Audit
- Least Privilege Principle: Scoped permissions restricted to
contents: readandissues: write. - IP Leak Prevention: Explicit assertions ensure traffic never falls back to unproxied runner egress.
- Zero Secret Leakage: No credentials or sensitive data are printed or passed into shell environments unsafely.
4. Verification & QA Gate 1 Alignment
- CI Pipeline: Run #38136379075 passed 100% GREEN (Lint & Static Analysis, Hermetic Unit Tests, Docker Container Smoke Test).
- QA Sign-off: Gate 1 completed and approved by QA Engineer (Comment #6108664544).
5. Gate 2 Decision
All criteria under Quality Gate 2 (ADR-006) are fully satisfied. Proceeding with merge.
Summary
Fixes the root cause of the daily canary verification failure (Issue #7, Run #38132855969 & #38135968825).
Root Cause Analysis
During live canary testing,
curlconnects tohttps://check.torproject.org/api/ipover newly established Tor circuits.In volatile Tor relays, TLS handshakes frequently experience transient resets or timeouts (
curlexit code 35:CURLE_SSL_CONNECT_ERROR). Under strictbash -e, a single un-retried network glitch immediately terminated the workflow and created false-positive canary alert issues.Changes
--retry 2 --retry-all-errorsand exponential delay.api.ipify.org) ifcheck.torproject.orgis temporarily unreachable or rate-limiting, still strictly verifying that traffic routes via Tor and does not match the Runner Host IP.docker logs torproxy-canary) for immediate troubleshooting.canary-alertissues when a verification run succeeds.Closes #7.