Python crawler ignores `.egg-info` installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to `scan -g`
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 55/100
Hướng nghiên cứu
Start at crates/socket-patch-core/src/crawlers/python_crawler.rs:1576-1584 and trace how discovery feeds find_each_by_purl and the hosted probe in crates/socket-patch-cli/src/commands/scan/hosted/python.rs:76. Read crates/socket-patch-cli/tests/in_process_python_envs.rs:455 as the regression target. Done means directory and bare-file egg-info installs are covered by agent, hosted stale-install, and -g behavior, with the regression coverage passing.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
[agent] Found by the scheduled pip / requirements.txt bug-hunt routine (ledger #309).
Summary
The Python crawler only recognises *.dist-info directories. When pip before 23.1 installs a package from an sdist and the wheel package isn't installed, it uses the legacy setup.py install path. That path writes <name>-<version>-pyX.Y.egg-info instead of .dist-info. This is the default state of a fresh python -m venv on CPython ≤ 3.11, which ships setuptools but no wheel, so it affects every pip release from 20 through 23.0.x (Ubuntu 22.04's pip 22.0.2 and Debian 12's pip 23.0.1 included).
socket-patch never sees these packages, which are really installed and importable:
- Agent mode (
scan --mode agent,get) reports the package as[skip] … (not installed; run your package manager's install first …)witherrorCode: package_not_installed, then exits 0 /success. The installed file stays unpatched. - Hosted mode (the default
scan) rewritesrequirements.txtto the hosted wheel. pip then keeps the same-version egg-info install (Requirement already satisfied), so the patched bytes never land. Theredirect_pypi_stale_installguard doesn't fire, because it uses the same crawler lookup (find_each_by_purl). The user gets no signal that the venv is still vulnerable. - Global mode (
scan -g,--global-prefix) omits these packages from the report. On Debian/Ubuntu that also includes every apt-installed Python package (python3-sixetc. shipsix-1.16.0.egg-info). In this sandbox,scan -gsent 102 purls and left out[email protected],[email protected],oauthlib,launchpadliband other egg-info packages.
Impact
Silent false negatives. A vulnerable, patchable package is reported as "not installed" (agent) or quietly left stale (hosted), and the command still exits 0. The hosted case is the worst: the documented safety net is the stale-install warning, and it never fires.
Repro (Linux shown; the probe covers macOS and Windows)
python3.11 -m venv .venv
.venv/bin/pip install -q 'pip==23.0.1' # also 20.3.4, 22.3.1
.venv/bin/pip uninstall -y wheel || true # default venv state on py<=3.11 anyway
echo 'six==1.16.0' > requirements.txt
.venv/bin/pip install --no-binary six -r requirements.txt
ls .venv/lib/python3.11/site-packages | grep six # six-1.16.0-py3.11.egg-info, six.py
socket-patch scan --mode agent --yes --json # apply.patches[0] = skipped / package_not_installed, exit 0
socket-patch scan --yes --json # hosted: redirect.warnings == [] (no redirect_pypi_stale_install)
.venv/bin/pip install -r requirements.txt # "Requirement already satisfied" -> still unpatched
socket-patch scan -g --global-prefix .venv/lib/python3.11/site-packages --json # six not reported
The patch data came from a local mock of the authenticated patch API (the same batch / by-package / view / package shapes as tests/docker_e2e_pypi.rs) serving a marked six.py. pip, the venvs and the installs were all real.
Expected vs actual
- CLI_CONTRACT.md "Python stale-install guard": "after a hosted redirect,
scan/getuse the Python crawler to inspect every matching installed package … A readable file that differs from the patch'safterHashemitsredirect_pypi_stale_install". Actual: an installed egg-info copy isn't inspected, and no warning fires. - docs/ecosystems.md lists PyPI agent mode as "✅ in place". Actual: pip's own legacy install layout is reported as "not installed" and isn't patched.
- The maintainer's
-gchecklist (ledger #309) saysscan -gmust find every globally installed package that has a patch. Actual: egg-info installs are missing.
OS × version matrix (probe run 36836217323, plus local Linux runs)
| OS | Python | pip 20.3.4 | pip 22.3.1 | pip 23.0.1 | pip 23.1 (control, writes dist-info) |
|---|---|---|---|---|---|
| ubuntu-latest | 3.8.18 / 3.11.16 | fail | fail | fail | pass |
| macos-latest | 3.8.10 / 3.11.9 | fail | fail | fail | pass |
| windows-latest | 3.8.10 / 3.11.9 | fail | fail | fail | pass |
| Linux (local) | 3.10, 3.11 | fail | fail (21.3.1 too) | fail | pass (24.0 too) |
"fail" means all of: agent skipped/package_not_installed with the marker absent, hosted with no redirect_pypi_stale_install and the file still unpatched after pip install -r, and -g not reporting six. Each pip 23.1 cell gives agent added with the file patched, the stale warning present, and -g reporting six.
First bad version
Not a regression. Released v4.0.0 (PyPI socket-patch==4.0.0) behaves the same way: [skip] pkg:pypi/[email protected] (not installed …). crates/socket-patch-cli/tests/in_process_python_envs.rs:455 (pypi_egg_info_layout_handled) pins the gap as the "current contract" and asks for the assertion to be flipped once egg-info support lands. No user-facing doc mentions the limitation.
Suspect code
crates/socket-patch-core/src/crawlers/python_crawler.rs:1576-1584:list_dist_info_packages_synckeeps only entries ending in.dist-info. It feedsfind_each_by_purl(:1529), which the hosted stale-install probe uses (crates/socket-patch-cli/src/commands/scan/hosted/python.rs:76), and the crawl / apply lookups.- Egg-info metadata lives in
<dir>.egg-info/PKG-INFO, or in a bare.egg-infofile (distutils / some distro packages, e.g.PyGObject-3.48.2.egg-info). It has the sameName:/Version:headers asMETADATA. Filenames can carry a-pyX.Ysuffix.
Probe
- https://github.com/SocketDev/socket-patch/actions/runs/36836217323 (6 jobs: ubuntu / macos / windows × py3.8 / 3.11 × pip 20.3.4 / 22.3.1 / 23.0.1 / 23.1)
- Ngôn ngữ chính
- Rust
- Star
- 8
- Fork
- 0
- Merge trung bình
- 1 ngày 7 phút
- Pull request đã merge (30 ngày)
- 178
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của SocketDev/socket-patch
-
Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap)Có thể đã có người làm @mikolalysenko đã nhận hôm nay. Đang mởagent:claimed agent:triaged bug bughunt pm:yarn-classic priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
SocketDev/socket-patch#907 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:npm priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
SocketDev/socket-patch#900 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:bundler priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
SocketDev/socket-patch#896 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
SocketDev/socket-patch#783 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:pipenv priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
SocketDev/socket-patch#744 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của SocketDev/socket-patch
Issue tương tự
-
Signals (Failure Detector): a tool call and its own execution are reported as a repeated callĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
check: a failed re-read of the model file before binding is labelled E_THETA_LEVEL_BINDING on [parameters]Có thể đã có người làm @TeunP đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 80/100
Devolutions/picky-rs#546 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày