Repository navigation
[Bug] MSYS原生参数/编码缺少警示,run_code路径重写及unconfined反馈边界不一致 #23
Description
问题概述
在 Windows / Git for Windows 下核验原生程序与 run_code 后,确认存在兼容提示不足、源码路径扫描边界及 unconfined 反馈不完整的问题。前三项基础现象属实;“run_code 源码路径完全不翻译”对当前实现已过时,但仍有漏翻和误改。
这是 #1 / #14 的后续可观测性与兼容性问题,不要求重做其已裁定的执行器架构,也不把文案修复冒充真正 shell 沙箱或通用编码修复。
环境及证据范围
- Windows;Git 2.56.0.windows.2;Git for Windows bash 5.3.15;测试 Node v24.13.0。
- 实际安装的 DSH Core 工具、shell/subprocess 组件 0.2.1-alpha.2。
- 原审计基线是route B 后续修复提交,其内容已随 修复:route B 工具接线、动态配置与异步卸载回归 #22 进入上游 v0.39.2。
- 参数/编码使用真实 Windows 进程与实际 Core
ToolRuntime → 自有 bash → 私有 GitBashSandboxExecutor → LocalSubprocessRuntime隔离链核验;不是仅凭脚本预测。 - run_code 派发使用真实 Core transport 和内存 mock PTC runtime 捕获程序;没有冒称真实 PTC 引擎或生产 GUI 端到端执行。网络配置内容未公开,记录只保留状态、字节数及安全标题。
复现与根因
1. MSYS 原生斜杠开关
ipconfig /all:exit1;native 实际收到类似C:/Program Files/Git/all。ipconfig //all或单命令MSYS2_ARG_CONV_EXCL=/all ipconfig /all:exit0。cmd /c echo COMPAT_ARGS_SENTINEL:exit0,但 sentinel 不存在,只有 banner/prompt;//c或单命令 EXCL=/c 才执行预期 echo。- 工具描述没有解释该陷阱。EXCL 是前缀,不是精确参数:排除
/c也影响/c/...文件参数;全局 EXCL=* 会破坏 native 路径转换。
2. 原生输出编码
本机 ipconfig //all 成功输出1693字节;宿主按UTF-8读出出现262个U+FFFD,GBK解码标题为“Windows IP 配置”。LANG/LC_ALL=C.UTF-8不能改变该native输出。显式在原始字节边界GBK→UTF-8后显示正确。
宿主已经解码成字符串后无法可靠恢复丢失字节。同一Bash输出可混合UTF-8与GBK;错误的整流GBK解码甚至可零U+FFFD,不能凭替换数自动猜码。
3. Windows unconfined 可观测性
既有行为为受限请求走 unconfined。真实执行器隔离实验传 read-only/workspace-write,均可在夹具声明workspace之外、获准测试目录内写固定sentinel,confine次数0。
最终result有 enforcement:'unconfined',但执行句柄等待result前缺少对应facts;前台正文、后台摘要、初始后台登记/超时转后台没有等效警示。官方file write/edit的策略检查仍独立生效,不能约束任意shell代码。读取也不等于一律限定工作区。
4. run_code 边界
现有完整ASCII路径字面量已有重写,不能说“完全不翻译”。但已复现:
- 中文/组合字符及含#完整路径被字符白名单漏掉。
- 合法EOF行注释无换行,使整份重写弃权。
- String.raw及其他tagged templates按普通字面量转义,可能破坏raw/tag语义。
- codePaths=false时,模型提示仍承诺程序字符串会翻译。
- 插值/分拆根动态表达式/不确定slash仍可能不翻;未翻的/c/...由native Node落到当前盘符的c子目录。
- 词法重写仍无法判断字符串是不是HTTP路由、搜索数据或Bash command;不能通过无限扩大字符串匹配彻底解决。
建议处理和范围
- 修复Unicode完整路径、EOF注释、tagged-template保护和codePaths提示门控。
- 将native参数、UTF-8捕获/代码页边界写进登记的工具描述,不随路径方言关闭而消失。
- 将unconfined facts和警示贯穿前台/后台登记/后台结果/超时转后台。
- 文档区分“已修复”“尽力转换”“仍为平台/架构限制”。
已准备实验修复,后续PR将基于当前上游main仅提交本轮增量。
明确不做:全局MSYS2_ARG_CONV_EXCL=*、全局GBK/自动猜码、替换root PowerShell、改市场patch、改安全默认、静默回退其他shell或宣称已恢复Windows confinement。动态路径的可靠方向是native路径/显式类型化转换,而不是盲目改写所有程序数据。
验证
原实验修复:普通测试166/166;实际宿主无头preview17/17;实验分支CI通过。新增PTC测试是source capture,不运行真实引擎。未验证AppContainer或新restricted-token方案;历史失败不扩大为“所有未来版本永远无解”。
Activity
KannaKuron commentedon Oct 13, 2026
感谢这份报告——四个问题我们都对照 v0.39.2 源码逐条核实了,结论全部认可:
GITBASH_MSYS_ADDENDUM只覆盖路径方言、且随dialectApplies门控消失;参数转换陷阱(ipconfig /all、cmd /c)是 Git Bash 二进制固有行为,确实应放进不受方言开关门控的描述层。enforcement: 'unconfined'已盖进 result 对象并透传,但renderResult/renderPromoted/后台登记与摘要均无 marker,一次性 console.log 只进宿主日志——对用户明示了、对模型没有,这确实擦边「明示 unconfined」的既有红线。修复方向(警示贯穿前台正文/后台登记/后台结果/超时转后台)是对的。CODE_LITERAL_SAFE白名单漏 CJK/#、EOF 行注释无换行导致整份弃权、tagged template 无法识别(写入侧转义在 raw 语义下会改错路径)、runCodeHintFor不读codePaths开关。其中「插值/动态表达式不翻」是我们 §4c 既定边界,报告的定性(词法重写无法根治、正确方向是显式类型化转换)与我们的设计哲学一致。你的「明确不做」清单与仓库既有裁决逐条吻合,实验分支的改动面我们也过了一遍,没有越界项。
欢迎提 PR——review 时我们会重点核两处:① run_code 三处边界修复(EOF 注释放松、白名单扩展、tagged template 处理)是否保持「任何不确定 = 整份 no-op」的铁律;② unconfined 警示是否为纯加法 marker,不污染对官方 render 的镜像语义。基于上游 main 的增量 PR 到了我们会尽快审。
fix: MSYS compatibility boundaries, run_code scan edges, unconfined f…