feat(pipelines): add pr_to_env + v2 iptables egress firewall

[adithya-s-k]

Summary

• New pipeline pr_to_env — the import-shape sibling of pr_runtime. Takes an explicit list of PR URLs (url=… or urls_file=…) and emits one Harbor task per URL, oracle-gated in-loop. Fills the dataset-curation gap where mine-then-filter is the wrong tool. Registered as experimental=True.
• Egress firewall v2 in _env_guard.py — replaces the bypassable /etc/hosts blackhole with iptables OUTPUT DROP + IP allow-list. Closes a confirmed reward-hack channel (opus + codex fetched fix content from raw.githubusercontent.com via IP-direct, sidestepping the v1 host guard).
• In-pipeline gates: oracle-gate that drops sub-1.0 envs, keepers.jsonl ledger, leak-strip v2 (short-SHA + pytest node-id), pyproject.toml sanitize (Dockerfile RUN step for [tool.pytest] / [tool.pytest.ini_options] collisions on peft).
• 34 tests added across test_pipeline_pr_to_env.py + test_env_guard.py; full suite 740/740 green, ruff clean, contract test conforms.

Reference dataset built with this pipeline: AdithyaSK/HF_ML_Bench_v0 (16 oracle-verified tasks across 5 HF ML repos, with 4-agent eval matrix baked into the README).

Closes #84

Test plan

• uv run pytest -q → 740 passed, 5 skipped
• uv run ruff check . → clean
• Contract test: new pipeline conforms to Pipeline Protocol
• Reference dataset built end-to-end: 16 tasks emit + oracle-verify + push to HF Hub

Out of scope

4 lower-frequency M3 gates still pending (parametrization suffix expansion, cross-repo dep pinning, salvage manifest tracking, LF-normalized content hash). Land as follow-ups — pipeline is honest about being experimental = True.

Version bump: not in this PR. Only after merge + review.

[KNambiarDJsc]

Reviewed and tested da423fa. This is a substantial, well-documented PR (RFC 0007 already exists on main for it) — went through the pipeline, the v2 firewall, and the CI blocker.

The one thing actually blocking CI is trivial. All three Lint (ruff) failures collapse to one: ruff format wants a single trailing blank line removed from the end of src/repo2rlenv/pipelines/_env_guard.py (ruff check itself is already clean). uv run ruff format src/repo2rlenv/pipelines/_env_guard.py fixes it in one commit — Tests (py3.12/13/14) are already green and have been since this opened.

Test suite: ran the full suite myself rather than trusting the PR description. Linux (WSL, matching CI's uv sync --group dev --all-extras --frozen): 739 passed, 6 skipped, 0 failed — matches your claimed 740/5 (the one extra skip in my run is just gh not authenticated in my sandbox). On Windows I saw 8 unrelated failures, all pre-existing Windows-portability gaps already tracked in #130 (bundle-mode checks, symlink privilege, etc.) — nothing here is this PR's fault, noting it only so it isn't mistaken for a regression.

Two things worth raising on the v2 firewall before merge, since _env_guard.py is this project's actual security boundary against reward-hacking (per CLAUDE.md's "the environment enforces, the prompt never asks" invariant), not just a nice-to-have:

1. IPv6 is completely unfiltered. egress_firewall_entrypoint() only ever calls iptables — ip6tables is never touched anywhere in the fragment, and getent ahostsv4 (grade.py:205 in the diff) explicitly discards any AAAA records it resolves. The default OUTPUT policy on the ip6tables table is left at whatever the base image ships (normally ACCEPT), so on any container with an IPv6 route, an agent can reach raw.githubusercontent.com (or anything else) over its AAAA record and the entire v2 guard — including the exact IP-hardcoded-connection bypass this PR was written to close — is void. Docker's default bridge network has IPv6 disabled, which is probably why this hasn't shown up yet, but the PR targets 5 different sandbox providers (Modal/Daytona/E2B/Runloop, per the project's own docs) and some of those enable dual-stack by default. Given the docstring's claim ("Blocks all outbound traffic at the packet layer except a small allow-list") is currently only true for IPv4, I'd treat this as worth closing before relying on it, even if just ip6tables -P OUTPUT DROP unconditionally (no allow-list needed there, since none of DEFAULT_ALLOW_HOSTS need to be reached over v6 if their v4 addresses are already allowed).
2. Port 53 is allowed to any destination, not just the container's resolver. iptables -A OUTPUT -p udp/tcp --dport 53 -j ACCEPT has no -d restriction, so DNS-tunneling to an attacker-controlled external nameserver (a well-known exfil/infil channel, and squarely in the threat model this PR names — "DoH resolvers bypass it entirely") isn't actually closed, just narrowed to port 53 specifically. Restricting to the container's actual resolver (-d 127.0.0.11 for Docker's embedded DNS, or read from /etc/resolv.conf at entrypoint time) would close this the same way the rest of the allow-list does.

Neither of these undoes the real improvement here over v1 (IPv4 IP-hardcoded bypass is genuinely closed), and I don't have visibility into whether IPv6 is even reachable on the sandbox providers this runs against in practice — flagging them because this is the file the project explicitly trusts to make reward-hacking structurally impossible rather than just discouraged, so it seemed worth having on the record before merge rather than after.

pr_to_env.py's subprocess call (_run_oracle_gate) passes an argv list with no shell=True, so no injection concern there — spot-checked it since it's the one place PR-URL-derived input reaches a subprocess.

LGTM on the mechanical/functional side once the one-line format fix lands; the two firewall points above are for you and the maintainers to weigh, not blockers I'm asserting.

[adithya-s-k]

Closing this since PR-to-env is now covered by Tasksmith and the SWE-gen pipeline on main. Keeping the branch for reference; any remaining firewall improvements can come as a separate focused PR.