发现一些DSH的安全问题，请问该通过什么渠道进行反馈？

[ybdesire]

请问安全问题（漏洞）的反馈渠道是什么？

[zoahdev]

The current channel is GitHub Discussions ? issues and PRs are closed upstream, and security reports are already being discussed there (#1923, #1863, #1789 are recent examples). Post with this template so maintainers can act fast:

• Environment: OS, dsh version, surface (web/TUI/headless)
• Reproduce: minimal steps (ideally a script/PoC)
• Impact: what an attacker gains, who is affected
• Evidence: logs, source line, screenshot ? redact anything personal

Two gaps worth flagging upstream while you're at it:

1. The repo has no SECURITY.md ? a responsible-disclosure policy would make the channel explicit.
2. A private report path (security@ / GitHub private vulnerability reporting) is absent; for now Discussions is public-by-default, so avoid including live credentials.

I maintain the ecosystem bug radar (https://github.com/zoahdev/dsh-ecosystem) ? happy to track your finding there with a link back to your report.

[denial123789]

建议先不要在 Discussion、Issue、PR 或公开附件里提供漏洞细节、利用代码、真实路径、凭据或未脱敏会话记录。

我刚核对了仓库当前的公开配置：

• GitHub Private Vulnerability Reporting 当前未启用；
• 仓库根目录当前没有 SECURITY.md；
• Community Profile 也没有列出安全策略入口。

因此目前不能可靠地指向一个“官方私密上报渠道”，也不应该猜测邮箱。比较安全的临时做法是：保留本帖作为不含细节的占位，只写受影响版本、平台和影响类别，并请维护者在这里提供私密联系方式。拿到官方渠道后，再私下发送最小复现、影响范围、环境、日志和建议修复方式。

同时建议维护者尽快启用 GitHub Private Vulnerability Reporting，并增加 SECURITY.md，明确支持版本、响应预期和披露流程。这样后续报告者可以直接使用仓库 Security 页面的 Report a vulnerability。

[zoahdev]

如果这个反馈渠道说明对你有帮助，方便的话可以把我的回答标记为采纳（Mark as answer）。以后发现 DSH 安全问题的社区用户可以直接看到当前可用渠道和上报模板（环境/复现/影响/证据）。

If the channel guidance helped, accepting the answer would make it easier for future security reporters to find the recommended process.

[zoahdev]

把"怎么系统地审计一个小插件"写成了完整方法论——七项清单 + 三个真实靶标的审计记录（全部干净，含文件+行号证据），以及"没发现也是资产"的原则：

How to systematically audit a small plugin — https://zoahdev.github.io/blog/2026/08/17/how-to-audit-a-small-plugin.html

对想给 DSH 生态做安全贡献的人应该有用：选靶（处理不可信输入的小包）→ 先读风险文件 → 全仓搜高危 API → 验证防御而非只看关键词 → 只报站得住的发现。

[Delafroms]

整理了一个针对这 5 个 QVD 的社区补丁仓库（基于 0.1.2-alpha.2）：52631/52632/52644/52646 四个有源码修复，57410 是版本核验；附逐项说明、Windows 一键验证脚本和 SHA-256。52632 的进程级读面残留也如实标注了，非官方发布，仅供参考。https://github.com/Delafroms/dsh-qvd-fixes

[pica9678]

新開發的軟體軟件多多少少都會有漏洞,其實我一直覺得官方能給SSL加密功能內部區網IP功能使用比較方便不是,雖然可能更不安全但這樣使用率就能提高,不可能一直在單台筆電前面,安全性是可增加改善的

[Delafroms]

这个的话，我在我的 QVD-fixes 仓库里提到过，目前发现的 QVD 漏洞中，有五个是可以形成链式反应的，所以我认为这几个漏洞的危机等级已经非常高了。

我不否认任何新开发的软件多多少少都会有一定的安全问题，漏洞本身就是为了提前发现这些问题而存在的，零日漏洞也是如此。

尤其是 AI 的安全性漏洞，我们更应该谨慎。

如果要让我说得形象一点，我会把 AI 看作是一把斧头。斧头本身只是工具，但如果这把斧头被“感染”或者被恶意利用，那么总有一天它会被用坏。只不过在网络上不存在所谓的“耐久性”，漏洞不会因为你用了很久就自己消失，所以安全程序员才总是要花大量时间去发现、修复和验证漏洞。

这也是为什么我在 QVD-fixes 里面提到，我这次并没有去修复外部恶意脚本。

不是说外部恶意脚本不重要，而是为了划清边界。

我不希望因为“这个漏洞修好了”，就夸大成“这个软件已经安全了”，然后用户因为看到漏洞被修复，就降低自己的安全意识，觉得可以放心继续使用，最后又因为其他漏洞或者其他攻击方式被入侵。

这其实是我认为我们很容易忽略的一点：

修复好了 → 个人安全意识下降 → 放心继续用 → 又被利用漏洞 → 实质上的安全问题还是没有解决。

所以我更希望 QVD-fixes 能明确告诉别人：哪些问题被修复了，哪些问题没有修复，以及修复之后还剩下什么风险。

毕竟修复漏洞的目的应该是降低风险，而不是让人产生“已经完全安全了”的错觉。