hermetic test children inherit GOFLAGS, GOENV, GOWORK, GOPATH and GOMODCACHE, which the go crawler and apply read; two hosted-production Go/Deno tests can't fail

Ouverte
  • Quelque chose ne va pas ?
#1,981 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
55/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
deno, go, rust
Domaine
testing

Piste de recherche

Start in crates/socket-patch-cli/tests/common/hermetic.rs, where the Extra enum and CRAWLER_EXTRAS live, and add a Go variant that scrubs GOFLAGS, GOWORK, GOPATH and GOMODCACHE and sets GOENV=off. Then replace the process-wide set_var calls in e2e_golang_build.rs and e2e_golang_hosted_build.rs with per-Command .env(..). Done means the four Go suites pass with GOFLAGS=-modfile=/nonexistent exported in the parent shell, and the two hosted-production tests in e2e_hosted_production.rs can fail.

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

Description

agent:triaged arch-audit bug priority:p3

[agent] Filed by the scheduled architecture audit (audit-cli-tests). Register: register.

Kind: bug (test hermeticity). Register ID: T66.

Problem

The CLI reads Go settings from the environment and from the Go env file:

  • go_env reads the variable, else the GOENV file, else $XDG_CONFIG_HOME/go/env (L110-L116).
  • The go crawler resolves the cache through GOMODCACHE and GOPATH (go_crawler.rs L186-L189).``
  • Go apply and vex honor GOFLAGS=-modfile (#1799), and vendor reads GOWORK.

The test scrub has an Extra for each other crawler that reads the environment (Venv, Bundle, Composer, Pdm, Poetry), but none for Go. CRAWLER_EXTRAS is [Venv, Bundle, Composer]. Every socket-patch child therefore inherits the developer's or runner's Go environment.

Consequences found while auditing:

  • Two hosted-production tests can't fail. In e2e_hosted_production.rs:
    • golang_hosted_redirects_only_via_goproxy_override writes a go.mod with no require and no go.sum. The crawl therefore walks the ambient GOMODCACHE/$HOME/go, and on a clean runner only "scan exit 0" is asserted.
    • deno_hosted_is_unsupported installs nothing, so it gets 0 pins whether or not hosted Deno is supported.
  • Process-wide env set and never restored.
    • e2e_golang_build.rs sets GOTOOLCHAIN with std::env::set_var and never restores it (L198). The binary has no serial_test, so sibling tests read the environment in parallel while it is set.
    • e2e_golang_hosted_build.rs sets GOTOOLCHAIN, GOFLAGS=-mod=mod and GONOSUMDB=* the same way (L376-L378).````` Its later CLI children and in-process discovery see these values depending on test order.
  • Only GOMODCACHE is pinned. run_socket pins GOMODCACHE only, so an ambient GOFLAGS=-modfile=… or a user go/env file reaches apply/apply --check.
Proposed change
  1. Add Extra::Go to hermetic.rs:
    • remove GOFLAGS, GOWORK, GOPATH and GOMODCACHE;
    • set GOENV=off.
  2. Include Extra::Go in CRAWLER_EXTRAS. Tests that need a value set it after the scrub, as they already do.
  3. Replace the process-wide set_var calls with per-Command .env(..) on the go and CLI children. Failing that, use a restoring guard under #[serial].
  4. In e2e_hosted_production.rs:
    • Give the golang leg a require + go.sum and a fixture GOMODCACHE, and assert the pin or skip code.
    • Install a Deno tree and assert a hosted_skips code, or delete the test.
Size

3–4 test files. About +40/−30 lines.

Acceptance criteria
  • With GOFLAGS=-modfile=/nonexistent and GOMODCACHE=/tmp/x exported in the parent shell, these suites still pass: e2e_golang, e2e_golang_build, e2e_golang_hosted_build and e2e_vendor_golang_build.
  • A hermetic selftest shows that the Go variables don't reach the child.
  • The two production tests fail when their claimed behavior is broken.
Langage dominant
Rust
Étoiles
9
Forks
2
Merge moyen
20 h 47 min
PR mergées (30 j)
681

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.