Repository navigation
chore: dependency refresh and compatibility/docs alignment (aiodns 4.x, tests, CI) - #230
Merged
Merged
Conversation
Issue #105 has been open since 2022, originally about consolidating onto Poetry-only. With uv 0.11.13 mature and 10-30× faster than Poetry, the calculus shifted. Migrate the entire dev/CI/Docker toolchain to uv in one pass. Why uv now: - 10-30× faster resolve (matters most across the Py 3.10-3.14 CI matrix) - PEP 621 [project] + PEP 735 [dependency-groups] native (standards-track, not Poetry-specific) - Single binary replaces Poetry's role for install/lock/sync/run - Build backend stays poetry-core>=2.1.3; poetry-core 2.x reads PEP 621 natively, so PyPI publish (`python -m build`) keeps working unchanged Migration scope (one-pass per the matrix-audit-fix-in-one-pass methodology from PR #225 / PR #210): pyproject.toml - [tool.poetry.*] sections → PEP 621 [project] + [dependency-groups.dev] - caret constraints (^X.Y.Z) → PEP 440 explicit ranges (>=X.Y.Z,<(X+1).0.0) - ruff added to dev group (was previously installed ad-hoc in CI) - pytest-runner dropped (deprecated, no longer needed) Lockfile transition - Generated fresh uv.lock (33 packages resolved in 642ms) - Verified resolution parity vs poetry.lock: no major-version drift on any direct dep; only minor/patch bumps within constraints - Deleted poetry.lock; removed uv.lock from .gitignore CI workflows - python-test-versions.yml: snok/install-poetry → astral-sh/setup-uv@v8.1.0 (SHA-pinned), poetry install → `uv sync --locked --dev`, all `poetry run` → `uv run`. Added `enable-cache: true`. - py-to-exe.yml: same pattern. pyinstaller installed via `uv pip install` (build tooling, not a project dep). - python-publish.yml: unchanged (already uses `python -m build`). Dockerfile - pip install poetry → COPY --from=ghcr.io/astral-sh/uv:0.11.13 (tag+digest pinned, same pattern as the python:3.14-slim base). - Multi-stage layout: deps layer (`uv sync --no-install-project --no-dev`) separated from project layer for better cache hit rate. - ENTRYPOINT keeps `python -m proxybroker` via PATH=/app/.venv/bin. Docs - README "Development Setup": Poetry → uv (with `curl install uv` snippet for new contributors); Development Tools list updated. - CLAUDE.md "Setup" + "Known Quirks" sections: Poetry → uv; clarified that poetry-core remains the build backend. Verification (all green locally before push): - uv lock: 33 packages, 642ms - uv sync --locked --dev: succeeds - uv run pytest -x: 293/293 passing - uv run ruff check . + ruff format --check .: clean - python -m build: sdist + wheel both build (validates poetry-core 2.x reading PEP 621 metadata) - docker build + docker run --rm proxybroker2:uv-test --help: image builds in ~4s, CLI invokes correctly Out of scope: - docs/requirements.txt: used directly by ReadTheDocs, not part of dev workflow. Left as-is. - MANIFEST.in: setuptools artifact, no change. - .pre-commit-config.yaml: uses ruff/bandit standalone, no change. Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request migrates the project from Poetry to uv for package management, updating the Dockerfile, development documentation, and pyproject.toml to use PEP 621 and PEP 735 standards. Feedback points out several version hallucinations for dependencies like attrs, ruff, and the uv Docker image that would lead to build failures. Additionally, a redundant apt-get upgrade command was noted in the Dockerfile's builder stage.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughMigrates the repository from Poetry to uv: pyproject moved to PEP 621, lockfile and ignore rules updated, CI and PyInstaller workflows use uv, Docker build copies uv binaries and runs two-stage syncs, pre-commit exports requirements.txt, and docs updated for uv commands. ChangesDependency Toolchain Migration from Poetry to uv
🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit hops from Poetry's nest, Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
Dockerfile (1)
51-55: 💤 Low valueConsider adding
--no-install-recommendsto reduce image size.The
apt-get installcommand could benefit from the--no-install-recommendsflag to avoid installing unnecessary recommended packages, reducing the final image size. This is a Docker best practice for production images.📦 Proposed optimization
RUN apt-get update && \ apt-get upgrade -y &&\ - apt-get install -y gcc libc-dev libffi-dev && \ + apt-get install -y --no-install-recommends gcc libc-dev libffi-dev && \ apt-get clean && \ rm -rf /var/lib/apt/lists/*🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile` around lines 51 - 55, The RUN instruction that installs build dependencies should use apt-get install --no-install-recommends to avoid pulling recommended packages and reduce image size; update the RUN line containing "apt-get install -y gcc libc-dev libffi-dev" to include the --no-install-recommends flag and keep the existing apt-get clean && rm -rf /var/lib/apt/lists/* cleanup so temporary package metadata is removed.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pyproject.toml`:
- Line 15: Update the attrs dependency entry in pyproject.toml to add an upper
bound consistent with other packages: change "attrs>=25.3.0" to a bounded
constraint such as "^25.3.0" or ">=25.3.0,<26.0.0" so the project pins the major
version and avoids accidental breaking upgrades; locate and modify the attrs
line in the dependencies section accordingly.
---
Nitpick comments:
In `@Dockerfile`:
- Around line 51-55: The RUN instruction that installs build dependencies should
use apt-get install --no-install-recommends to avoid pulling recommended
packages and reduce image size; update the RUN line containing "apt-get install
-y gcc libc-dev libffi-dev" to include the --no-install-recommends flag and keep
the existing apt-get clean && rm -rf /var/lib/apt/lists/* cleanup so temporary
package metadata is removed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 7a448b15-7a4e-4350-9a07-3aad0e96814c
⛔ Files ignored due to path filters (2)
poetry.lockis excluded by!**/*.lockuv.lockis excluded by!**/*.lock
📒 Files selected for processing (7)
.github/workflows/py-to-exe.yml.github/workflows/python-test-versions.yml.gitignoreCLAUDE.mdDockerfileREADME.mdpyproject.toml
💤 Files with no reviewable changes (1)
- .gitignore
Snyk's Python plugin doesn't yet support uv.lock files (snyk-python-plugin #251 still open as of 2026-05-11), so the snyk PR check errors when poetry.lock disappears in the migration. Generate requirements.txt from uv.lock as a snyk-readable manifest until upstream support lands. - requirements.txt: generated via `uv export --format requirements-txt --no-dev --no-emit-project`. Includes hashes; ~954 lines. - .pre-commit-config.yaml: add a local hook that auto-regenerates the file whenever uv.lock or pyproject.toml changes. Uses `language: system` so it runs against whatever uv is on PATH. - CLAUDE.md: document the workaround and the upstream issue, with a note to remove this once Snyk ships uv support. Tradeoff: one auto-generated file in the repo with a clear "don't edit by hand" mechanism. Better than carrying poetry.lock alongside uv.lock (which would defeat the migration's purpose) or making snyk a non-blocking check (security regression). Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
Snyk's pip parser handles the simpler `pkg==version` format more reliably than the hashed format. Switch the export and the pre-commit hook accordingly. Cuts the file from ~954 lines to ~53. Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1558779404
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
CI failure on PR #230 commit 1558779: build (3.12) failed because the runner used Python 3.12.3 (pre-installed on ubuntu-latest), not 3.12.11+. Two tests assert RFC 5952 IPv4-mapped IPv6 string format (`::ffff:192.0.2.1`), which Python only adopted in 3.12.4 (bpo-119891). Root cause: setup-uv's `python-version: "3.12"` doesn't install the LATEST 3.12 patch — it picks up whatever Python is already on PATH (the runner's older pre-installed version). Fix: install Python via `actions/setup-python` first (always picks the latest patch for the requested minor), then run setup-uv WITHOUT the `python-version` input. Pass `--python ${{ matrix.python-version }}` to `uv sync` to pin uv to the version setup-python provided. Same fix applied to py-to-exe.yml for consistency. Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
Owner
Author
|
CI status update on commit `51ed1f3`: All build/test/security checks pass except snyk. Snyk error explanation: Snyk's Python plugin doesn't yet support `uv.lock` (snyk-python-plugin#251 still open). I committed a generated `requirements.txt` (auto-regenerated by a pre-commit hook from `uv.lock`) as a snyk-readable manifest, but the snyk PR check still errors across 4 commits — the snyk app likely has the project configured to monitor `poetry.lock` specifically. The fix requires a one-time snyk org settings change I can't make from the repo:
Other security gates (CodeQL, SonarCloud, fossa, fossabot, semgrep) all green and unaffected. Alternative: keep `poetry.lock` alongside `uv.lock` during the transition. Doubles maintenance but avoids touching snyk config. |
Earlier `uv export ... > requirements.txt` shell-redirect captured uv's "Resolved N packages in Xms" status line into the file. Use `--quiet` plus `--output-file` so only the actual requirements end up in the file. Match the same flags in the pre-commit hook so future regenerations stay clean. Co-Authored-By: Claude <noreply@anthropic.com>
…nt floor Snyk preview (now enabled) parses pyproject.toml's [project.dependencies] correctly and flagged click@8.2.1 — the constraint `>=8.2.1` lets a vulnerable lower-bound version satisfy the requirement, even though uv.lock pins click==8.3.3. Audit of all dep lower bounds against snyk's vulnerability database: - click 8.2.1 → SNYK-PYTHON-CLICK-16347201, HIGH severity, command injection in click.edit() filename param. Fixed in 8.3.3. - aiohttp 3.12.0 → multiple HIGH vulns (SSRF on Windows static handler, memory exhaustion in multipart/Request.post/ZLibDecompressor, request smuggling). Fixed in 3.13.4+. - aiodns, attrs, maxminddb, cachetools, pyyaml: no known vulns at floor, bumped anyway for consistency with uv.lock. Strategy: align all dep lower-bounds with what uv.lock currently resolves. That's what CI tests against, so it's the right floor — also eliminates "lower-bound vuln" false positives from constraint-only scanners going forward. - aiohttp: 3.12.0 → 3.13.5 - aiodns: 3.4.0 → 3.6.1 - attrs: 25.3.0 → 26.1.0 - maxminddb: 2.7.0 → 2.8.2 - cachetools: 5.5.2 (no change) - click: 8.2.1 → 8.3.3 - pyyaml: 6.0.2 → 6.0.3 - pytest (dev): 8.3.5 → 8.4.2 - pytest-mock (dev): 3.14.0 → 3.15.1 - pytest-cov (dev): 6.1.1 → 6.3.0 293/293 tests pass with bumped constraints. Co-Authored-By: Claude <noreply@anthropic.com>
Snyk's GitHub PR app integration uses the legacy poetry parser even when the org has "uv preview" enabled — preview is CLI-only per their docs: https://docs.snyk.io/supported-languages/supported-languages-list/python/cli-support-for-uv Without [tool.poetry.dependencies] in pyproject.toml the snyk PR check fails with "pyproject.toml error Failed to detect issues" and never falls through to scan requirements.txt or uv.lock. The shim mirrors the just-bumped (and verified vuln-free) [project.dependencies] versions so snyk's legacy parser succeeds without finding any vulns at the constraint floor. Pre-commit hook still keeps requirements.txt in sync for redundancy. Will revert this whole [tool.poetry.dependencies] block once snyk's PR app integration uses uv preview natively (snyk-python-plugin#251). Build verified: `python -m build` produces wheel + sdist. Tests verified: 293/293 pass. Co-Authored-By: Claude <noreply@anthropic.com>
Triaged comments from coderabbit, gemini-code-assist, codex, and the ongoing snyk investigation. Three valid actionable items + one false positive class to flag. 1. Snyk: [tool.poetry] block was incomplete — Poetry requires name/version/description/authors as required fields. Without them, snyk's poetry parser rejects the block as invalid and reports "pyproject.toml error Failed to detect issues" before even getting to dependencies. Add the required identity fields, mirroring values from [project] above. poetry-core 2.x prefers [project] when both are present, so this duplication doesn't affect builds. Verified: `python -m build` produces wheel + sdist correctly. 2. coderabbit: attrs missing upper bound for consistency with other deps. Added `<27.0.0`. attrs uses year-based major versioning, so this caps at the next year boundary — same pattern as other caret constraints. Mirrored in [tool.poetry.dependencies] shim. 3. gemini-code-assist (medium) + coderabbit (nitpick): Dockerfile builder stage had redundant `apt-get upgrade -y` (already done in base stage) and missing `--no-install-recommends`. Removed the redundant upgrade and added the flag. Verified: `docker build` + `docker run --version` both work. 4. gemini-code-assist (3x "hallucination" comments on attrs 26.1.0, ruff 0.15.12, uv 0.11.13): false positives. All three are real, current package versions (verified via PyPI / GitHub releases / ghcr.io image registry). Gemini's training data appears to predate these releases; will reply on the comments rather than change code. 5. codex requirements.txt comment was already addressed in commit 7aa59b5 by adding `--quiet` to the export command — now generates clean output without the resolver status line. 293/293 tests pass. Docker image builds in ~4s. Wheel + sdist build. Co-Authored-By: Claude <noreply@anthropic.com>
…e error Backwards reasoning: at commit 51ed1f3 (NO [tool.poetry.dependencies]) snyk successfully parsed [project.dependencies] via its uv preview AND reported the click@8.2.1 vuln. Snyk CAN read PEP 621 deps with preview enabled; the parser was working. When I added [tool.poetry.dependencies] alongside in commit 283154b, snyk started erroring with "Failed to detect issues" — presumably because two competing dep declarations (PEP 621 vs Poetry-style) confuse the parser. The shim was the cause, not the fix. Now that the click bump in commit 28405e6 already cleared the only real vuln snyk had flagged, the simpler config (just [project], no shim) should make snyk happy. Keeping a comment explaining why the shim is deliberately absent so a future contributor doesn't re-add it. Build verified (wheel + sdist), 293/293 tests pass. Co-Authored-By: Claude <noreply@anthropic.com>
#105) Decision after deep evaluation: stay on Poetry as primary, add best-effort uv support for install/use. Closes #105 not as a full migration but as a deliberate "support both, canonical = Poetry" position. Why not full uv migration: - Snyk's GH App doesn't yet support uv.lock (snyk-python-plugin#251 open). Workarounds either break snyk parsing or create dual-lockfile drift risk with auto-security-patching bots (dependabot, snyk auto-fix PRs). - Maintainer has many repos; per-repo migration burden + ecosystem friction outweighs the speed gain today. - uv works fine for install/use from this repo via git+https; full migration can land later when the ecosystem catches up. Changes: 1. Bump dependency lower-bounds to clear known vulnerabilities at the constraint floor (snyk scans the lower bound when no specific version is locked): - click ^8.3.3 fixes SNYK-PYTHON-CLICK-16347201 (HIGH, command injection in click.edit() filename param). Was ^8.2.1. - aiohttp ^3.13.5 fixes multiple HIGH vulns (SSRF on Windows static handler, memory exhaustion in multipart/Request.post/ZLibDecompressor, request smuggling). Was ^3.12.0. - Other deps bumped to match poetry.lock current resolution: aiodns ^3.6.1, attrs >=26.1.0,<27.0.0, maxminddb ^2.8.2, pyyaml ^6.0.3, pytest ^8.4.2, pytest-mock ^3.15.1, pytest-cov ^6.3.0. - Dropped pytest-runner (deprecated, unused). - Added attrs upper bound per coderabbit review. 2. Regenerated poetry.lock with bumped deps. 3. README install warning expanded: do NOT install from PyPI (`proxybroker` AND `proxybroker2` names are squatted per #186 and pypi/support#10315). Always install from this GitHub repo via git+https. 4. Added uv-as-alternative install instructions alongside the existing pip instructions. Both go through git+https, never PyPI. uv invokes the build backend (poetry-core 2.x) which synthesizes PEP 621 metadata so `uv pip install git+...` and `uv add ... @ git+...` both work. 5. README contributor section: Poetry remains canonical; uv supported as a best-effort alternative for local dev (uv.lock NOT committed — avoids drift with the authoritative poetry.lock). 6. CLAUDE.md restored to poetry-primary state. Verified: - `uvx poetry install` succeeds with bumped deps - 293/293 tests pass via `poetry run pytest` - `poetry build` produces wheel + sdist - `docker build` succeeds, container runs - `uv pip install <source_checkout>` works (poetry-core builds the wheel, uv installs it, `proxybroker --version` returns 2.0.0b3) Co-Authored-By: Claude <noreply@anthropic.com>
bluet
changed the title
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e68eb3939b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
bluet
changed the title
…230) Codex review caught: README's contributor workflow runs \`poetry run ruff check / format\`, but ruff wasn't in [tool.poetry.dev-dependencies] — so a clean \`poetry install\` left contributors with "command not found: ruff" when they tried to lint/format per the docs. The CI workflow papered over this by running \`poetry run pip install ruff\` ad-hoc before invoking it. That kept CI green but broke the documented contributor flow. Fix: - Add \`ruff = "^0.15.12"\` to [tool.poetry.dev-dependencies]. Now \`poetry install\` provides ruff, matching README. - Drop the redundant \`poetry run pip install ruff\` from the CI workflow since ruff is now declared properly. - Regenerate poetry.lock (ruff 0.15.13 picked up; matches the same version range as the pre-commit hook in .pre-commit-config.yaml). Verified: \`poetry run ruff --version\` → 0.15.13. \`poetry run ruff check . / format --check .\` both clean. 293/293 tests pass. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7e22c9f962
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
README had v2.0.0b1 hardcoded in 9 places (install commands, section headers, callouts) from when that was the latest release. Current release is v2.0.0b3 per pyproject.toml. When I added uv install instructions in the parent PR, I blindly mirrored the existing v2.0.0b1 pattern instead of fixing the staleness — same "consider 3 steps further" miss the maintainer called out earlier. Fix: replace all v2.0.0b1 → v2.0.0b3. (Follow-up to keep in mind: every release needs a README sweep to update these strings. Future improvement: extract to a single "latest release" reference at top, or use shields.io dynamic badge that pulls from the latest GitHub release.) Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 27e562a8b2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Per maintainer review, README should be long-lived with minimal per-release maintenance. Stale-prone content moves to canonical sources or gets dropped. Removed (rots on every release/commit): - "v2.0.0b3" version strings in tagline, section headers, install commands, marketing callouts (9 occurrences total) - "131 tests passing" / "100% test coverage" claims (actual: 293 tests, 60% coverage minimum). Replaced with qualitative "comprehensive test coverage" — verifiable claim that doesn't rot. - Dep version pins in Requirements section (aiohttp 3.12.0+, aiodns 3.4.0+, etc.) — duplicated info from pyproject.toml that goes stale on every bump - Dev-tool version pins (pytest 8.3.5+, pytest-cov 6.1.1+, ruff X.Y) — same reason; pyproject.toml is authoritative - Embedded `--help` CLI output (~40 lines) — went stale per CLI flag change. Replaced with `python -m proxybroker --help` pointer. - "What's New in v2.0.0b3" section — version-by-version changelog belongs in CHANGELOG.md, not README Restructured (one marketing section, one migration guide): - New "What's New in ProxyBroker2" merges three previously-overlapping sections (the old "What's New in v2.0.0b3", "Why ProxyBroker2?", and "What's Improved vs v0.3.2" from Migration). Now describes what ProxyBroker2 gives over abandoned v0.3.2 — including IPv6 and custom providers that the b3 release actually added. - "Migration from ProxyBroker v0.3.2" becomes a pure how-to-migrate guide (Python version, install command, CLI usage diff, API compat) with a cross-link to the marketing section above. Updated to current security/UX direction: - Install commands drop @v2.0.0b3 tag — `git+https://...` always pulls latest from default branch. Note added pointing to GitHub Releases page for users who want to pin: "append @<tag> from Releases". - "Requirements" section slimmed to "Python 3.10-3.14" — the only thing users handle manually; all deps auto-installed. - "Development Tools" → "What contributors handle manually". Only Poetry + optional pre-commit. Dropped ReadTheDocs (project infra, not contributor tool) and dropped pinned versions of auto-installed dev tools. - Migrated TODO list to GitHub issue links (was 7 vague bullets). - Merged duplicate License sections at lines 636 + 683. - Removed redundant "TWITTER" badge link area at line 4 in the tagline (kept the badges below). Per-release maintenance now: zero. CHANGELOG.md is the only place that needs touching per version. Co-Authored-By: Claude <noreply@anthropic.com>
depintel-bot
Bot
added
lapisa:security-fix
…ory fixes) The FOSSA Security Analysis check on #230 and #238 reports 11 vulnerabilities. They come from poetry.lock on this branch, not from the resolver change: - aiohttp 3.14.1: 14 OSV advisories (4 HIGH, published 2026-08-03 and 2026-10-19/20), all fixed by 3.14.4. Locked to 3.14.5, the latest. - multidict 6.7.1: GHSA-54p9-h82j-f925 and PYSEC-2026-4244, fixed in 6.9.1. Kept on 6.x; 7.0 is a major release (istr can no longer be subclassed). - yarl 1.24.2 -> 1.25.1, required by aiohttp 3.14.5 (yarl>=1.25.1). OSV reports no advisories for any of the three locked versions. All three releases carry PyPI provenance from the aio-libs GitHub repositories. Only these three packages change. pyproject.toml is unchanged, the content-hash is unchanged, and the lock was written by Poetry 2.4.1 (same as the file header). Verified in a clean python:3.13 container: - this branch: 293 passed, ruff check clean - with #238 on top: 294 passed; live resolve of github.com, pypi.org and one.one.one.one succeeds through Resolver.resolve()
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad8df6015a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
depintel-bot
Bot
added
lapisa:security-fix
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 11 files
Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.
View guided diff | Turn on auto-fix | Re-trigger cubic
depintel-bot
Bot
added
lapisa:security-fix
* fix(resolver): read aiodns 4 DNSResult answers aiodns 4 query_dns() returns a pycares 5 DNSResult instead of a list of objects with .host. resolve() iterated the result directly and raised TypeError: 'DNSResult' object is not iterable on every real lookup. Read address records from DNSResult.answer[*].data.addr (skipping CNAME and other non-address records) and keep the legacy query() list shape. Adds a regression test built from real pycares 5 DNSResult/DNSRecord types. Found by Lapisa review of PR 230 (aiodns 3 -> 4 at resolver.py:550/552). * test: isolate DNSResult regression from shared cache Co-authored-by: bluet <51141+bluet@users.noreply.github.com> --------- Co-authored-by: Gaia (agent for bluet) <bluet@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: bluet <51141+bluet@users.noreply.github.com>
depintel-bot
Bot
added
lapisa:security-fix
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c230136e9b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
depintel-bot
Bot
added
lapisa:security-fix
…ignore note (review threads on #230) - README: plain "uv run pytest" after "poetry install" discovers the project, finds no [project] table and runs in its own environment, so Poetry's packages are not there. Keep "poetry run pytest" as the canonical command and show the uv form that targets Poetry's interpreter: uv run --no-project --python "$(poetry env info --executable)" pytest. Verified in a python:3.13-slim container with poetry 2.3.2 and uv 0.13.5: both commands run the suite, 294 passed. - .gitignore: the uv.lock note no longer suggests "uv sync" (unsupported with Poetry-only metadata, as the README says).
|
depintel-bot
Bot
added
lapisa:security-fix
5 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current branch is broader than a docs-only
uv syncfix. In addition to clarifying contributor setup, it includes dependency/packaging refresh work and compatibility fixes that affected runtime and tests.Dependency and packaging refresh
pyproject.toml.poetry.lock.setup.py(including removal ofsetup_requiresand updated test/runtime bounds).Runtime compatibility fix
proxybroker/resolver.pyto support bothaiodnsresolver APIs by usingquery_dnswhen available and falling back toquery.Test compatibility updates
aiodns.DNSResolvermethod dynamically (query_dnsvsquery).CI/docs/repo alignment
.github/workflows/python-test-versions.ymlto rely on declared dev dependencies instead of ad-hoc Ruff installation.README.mdguidance: Poetry remains canonical install path;uv syncis explicitly documented as unsupported with current Poetry-only metadata, whileuv run ...remains a supported command-runner workflow..gitignoreguidance foruv.lock.Scope summary: 11 files changed across workflow config, docs, dependency manifests/lockfile, resolver runtime logic, and related tests.