Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Hosted `rollback`, `remove` and the vendored takeover refuse a requirements.txt whose only requirements are hosted pins (`six==1.16.0` alone can be patched but never unpatched)

Ouverte
  • Quelque chose ne va pas ?
#410 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
74/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python, rust
Domaine
cli, devtools

Piste de recherche

Start at crates/socket-patch-core/src/patch/redirect/upstream/pypi.rs:597-603, especially the hash_mode decision, and reproduce the single-pin requirements.txt case with rollback, remove, and scan --mode vendored. Trace how hosted restoration handles pins, options, and editables; done means these commands restore or take over an all-hosted requirements.txt without the current refusal, while preserving the existing behavior for hashed files.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

agent:triaged bug bughunt pm:pip priority:p1

[agent] Found by the scheduled pip / requirements.txt bug-hunt routine (ledger #309).

Summary

v5 hosted rollback, remove and the hosted → vendored takeover (scan --mode vendored over a hosted pin) all refuse a requirements.txt when every requirement line in it is a hosted pin. The simplest project shape, a single six==1.16.0 line, can be patched by socket-patch scan but can't be un-patched or vendored afterwards.

The refusal comes from the upstream restore. It tries to infer pip's hash-checking mode from the other requirement lines, and when there are none it gives up:

cannot restore pkg:pypi/[email protected] to its upstream registry entry: every requirement in requirements.txt is a hosted pin, so whether the original used pip's hash-checking mode (`--hash`) is not derivable; restore it from version control instead (`git checkout -- requirements.txt`)

The same refusal fires when the only other lines are options or editables. For example, -e . plus a pin is refused, even though -e lines are incompatible with hash-checking mode, so the original must have been unhashed.

Impact

  • socket-patch rollback and socket-patch remove <purl> exit 1 (partial_failure / hosted_revert_failed) on single-dependency projects, on projects where every pin is patched, and on -e . + pin projects.
  • socket-patch scan --mode vendored on such a hosted project can't take over: Vendored 0 packages; 1 failed., exit 1, and the project stays hosted. The documented mode-takeover path (CLI_CONTRACT.md, "Takeover reconciliation (every hosted ecosystem, v5.0)") is unusable for these projects.
  • v5 keeps no hosted ledger, so the CLI can't undo the rewrite at all. The only remedy is version control.

Repro

Uses a local mock of the patch API that serves a patched six-1.16.0 wheel. It's the same shape as tests/vex_pypi_real_common::RealApi: POST /v0/orgs/test-org/patches/batch, /patches/package grant, /patches/view/<uuid>, and the wheel route. Linux, pip 24.0, CPython 3.11, main 2463257.

A="--api-url http://127.0.0.1:8765 --api-token fake --org test-org --patch-server-url http://127.0.0.1:8765"
mkdir p && cd p && printf 'six==1.16.0\n' > requirements.txt
socket-patch scan $A                      # Switched 1 package to hosted patches; rewrote 1 file.
socket-patch rollback --yes $A; echo $?   # Error: Cannot restore … not derivable …   → 1
socket-patch remove pkg:pypi/[email protected] --yes $A; echo $?   # same error → 1
socket-patch scan --mode vendored $A; echo $?               # Cannot vendor … not derivable … Vendored 0 packages; 1 failed. → 1

Variants I checked (scan, then rollback):

requirements.txt before scan rollback
six==1.16.0 refused
-e . + six==1.16.0 refused
six==1.16.0 --hash=… --hash=… (only line) refused
six==1.16.0 + idna==3.7 restored
--require-hashes + hashed six restored
--index-url … + six==1.16.0 + idna==3.7 restored
pip-compile hashed idna + six (LF and CRLF) restored byte-exact

Expected vs actual

  • Expected: CLI_CONTRACT.md, "Hosted unwind coverage", says every file wiring a pin is rewritten back to the default upstream entry. The pypi bullet lists what gets refused: pdm.lock without cross_platform, non-pure uv / pylock wheels, uv option filters, and uv 0.2 locks. An all-hosted requirements.txt isn't in that list. When no other requirement constrains the mode, either restored form, six==1.16.0 or six==1.16.0 --hash=… for every release file, installs with every pip, because there is no other line it could conflict with. A -e line also settles the mode as unhashed.
  • Actual: the pin is refused in rollback, remove and the takeover.

OS × version

OS pip / Python reproduces
Linux (sandbox) 24.0 / 3.11 (CLI-only; no pip step involved) yes, twice
ubuntu-latest (probe) 20.3.4 / 3.8 yes (rollback, remove and takeover all refused, exit 1)
ubuntu-latest (probe) 25.0.1 / 3.8 yes (rollback, remove and takeover all refused, exit 1)
ubuntu-latest (probe) 26.2.1 / 3.13 yes (rollback, remove and takeover all refused, exit 1)
macos-latest (probe) 20.3.4 / 3.8 yes (rollback, remove and takeover all refused, exit 1)
macos-latest (probe) 25.0.1 / 3.8 yes (rollback, remove and takeover all refused, exit 1)
macos-latest (probe) 26.2.1 / 3.13 yes (rollback, remove and takeover all refused, exit 1)
windows-latest (probe) 20.3.4 / 3.8 yes (rollback, remove and takeover all refused, exit 1)
windows-latest (probe) 25.0.1 / 3.8 yes (rollback, remove and takeover all refused, exit 1)
windows-latest (probe) 26.2.1 / 3.13 yes (rollback, remove and takeover all refused, exit 1)
all 3 OS (probe) 20.3.4 / 3.13 blocked: pip 20.3.4 can't run on 3.13 (no distutils)

The refusal is decided before any pip runs, so it doesn't depend on the pip version.

First bad

The code is new in 2463257 (#277), which replaced v4's ledger replay with the upstream restore. I didn't get a clean comparison: on v4.0.0, rollback of the same hosted project stopped at Manifest not found even though .socket/vendor/redirect-state.json existed.

Suspect code

  • crates/socket-patch-core/src/patch/redirect/upstream/pypi.rs:597-603: the (false, false) arm of hash_mode. --prefixed lines, -e included, are skipped before the mode tally (if code.starts_with('-') { continue; }).
  • Related: #376. The hosted writer always emits --hash, so the line itself never records the original mode. Once #376 / #383 switch unhashed files to a #sha256= fragment, the hosted line's own shape (--hash vs fragment) would say which mode to restore.

Probe run: https://github.com/SocketDev/socket-patch/actions/runs/36806309982

Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
18 h 4 min
PR mergées (30 j)
70

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.