Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#134 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
TypeScript
Star
0
Fork
1
Merge trung bình
3 giờ 35 phút
Pull request đã merge (30 ngày)
50

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của STRML/omp-classifier

Tất cả issue của STRML/omp-classifier

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.