Skip to content

fix: honor ports in IPv4 no_proxy entries#7586

Open
PEliet wants to merge 1 commit into
psf:mainfrom
PEliet:fix/no-proxy-ip-port
Open

fix: honor ports in IPv4 no_proxy entries#7586
PEliet wants to merge 1 commit into
psf:mainfrom
PEliet:fix/no-proxy-ip-port

Conversation

@PEliet

@PEliet PEliet commented Jul 18, 2026

Copy link
Copy Markdown

Summary

  • Honor host:port entries for IPv4 addresses in no_proxy.
  • Preserve existing matching for plain IPv4 addresses and CIDR ranges.
  • Add regression tests for matching and non-matching ports.

Problem

should_bypass_proxies already matches hostname:port entries for domain names, but the IPv4 branch only compares the hostname. As a result, an entry such as 192.168.0.1:5000 does not bypass the proxy for http://192.168.0.1:5000/.

This can send requests to a local or internal IPv4 endpoint through a proxy even when the user explicitly excluded that host and port in NO_PROXY or no_proxy.

Changes

  • Build the request's IPv4 hostname:port value when a port is present.
  • Match both the plain IPv4 address and the address with its port.
  • Add tests showing that the configured port bypasses the proxy while a different port does not.

Testing

  • python -m pytest tests/test_utils.py -q
  • Result: 230 passed, 1 skipped

@heardjalissa9-gif

This comment has been minimized.

OwenTanzer added a commit to OwenTanzer/codeflow that referenced this pull request Jul 22, 2026
A PR-mode file-layer request always re-resolves the PR's *current*
head server-side (resolveRef ignores any `ref` once `pr` is set, by
design -- that's what let the base-repository allowlist fix in round 2
work at all). Without telling the server what revision the parent
repository graph actually pinned, a PR receiving a new commit between
that graph loading and a file drill-down would silently analyze a
different revision -- exactly what MOO-70's revision-pinning
requirement exists to prevent:

  repository graph built at PR head A
  PR receives another commit
  user opens a file
  file graph silently built at PR head B

Fixed per the reviewer's own suggested approach: the client now also
sends expectedResolvedSha/expectedSourceOwner/expectedSourceRepo
(PR mode only) from the parent graph's own AnalysisContext.
validateFileRequest validates them; graph-file.js's new
assertRevisionStillExpected reuses
src/graph-ir/githubContext.js's assertContextPropagation (the same
mechanism MOO-68 built for exactly this class of check) to compare the
freshly-resolved revision against what was expected, before doing any
of the real work -- rejecting a stale drill-down with a clear 409
"the pull request has changed... refresh the repository graph" message
rather than silently proceeding.

Verified live against a real forked PR (psf/requests#7586, forked from
PEliet/requests): a request with no expectation still succeeds
(backward compatible), a request with a deliberately wrong
expectedResolvedSha is correctly rejected with the 409, and a request
with the actual current head sha passes through correctly -- closing
the loop on the one item flagged as unit-tested-only in the round 2
reply.

380/380 tests passing, build clean.
Samielakkad

This comment was marked as resolved.

giladax pushed a commit to giladax/intent-ai that referenced this pull request Jul 23, 2026
Implements Slice O2: every PR opened on a governed repo gets its verdict
with no human action.

Architecture (webhook-swap ready):
  - PrEvent dataclass (frozen, 7 fields) — the seam between poll and webhooks
  - PrEventSource abstract base; GitHubPollEventSource wraps list_prs today
  - O6 webhook endpoint maps GitHub payloads to the same PrEvent → same
    handler, zero rework at swap time (as designed)

Per new/updated head SHA:
  - Trailer links extracted from mirror (failure-safe; sync_org constructs
    LinkStore like first_results when none injected)
  - Analysis runs via run_analysis (idempotency cache skips repeats)
  - check:analyzed activity_events row emitted (failure-safe, absorbs U4)
  - Optional publish_comment gated by HARD RULE: non-giladax remotes (psf,
    pallets, …) NEVER receive comments; giladax requires publish_enabled:true
    in sync_meta.yaml; default OFF everywhere

Budget discipline: max_prs_per_repo caps per-pass analysis; list_prs capped
at 2 pages; sync_meta.yaml tracks seen SHA set and last_seen_updated_at.

CLI: `python3 -m quire.cli org sync [--loop --interval N] [--max-prs N]`

Live proof (tokenless, ≤20 API calls): one pass detected + analyzed
psf/requests#7586, pallets/itsdangerous#428, #1; verdicts
on the org cards; 3 check:analyzed rows in activity_events; publish guard
asserted OFF for all residents; registry state committed.

Also: github adapter list_prs gains updated_at field (backward-compatible).

Tests: 44 new offline tests (no live GitHub, no live Postgres); backend
707 passed, 1 skipped; app vitest (from app/) 59/59 green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016cmqJ7aie4Kap4ZsZraMF1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants