False Positive Alert: dsh-latest-windows-x64.exe flagged by SecureAge on VirusTotal

[RohitWaghire]

Hi team,

For reference, I was about to report about the false positive security flag on the latest windows build When I launched the dsh-latest-windows-x64.exe installer it flagged a security alert on Virus Total from one of the vendors.

Below is the date/time of the file analysis:

File Name: dsh-latest-windows-x64.exe

File Hash: d61cd8882f8b8a1251144320493ad27920d15139503eba2465b9579eee720cfc

Detection Score: 1/50 security vendors identified this file as malicious.

Flagging Vendor: Secure Age (marked as Malicious)

Other vendors' status: All other major vendors (Crowd Strike Falcon, Microsoft, Avira, Kaspersky, etc.) have marked the file as Undetected.
Because only a single engine (Secure Age) detects this, this seems almost certainly to be a false positive, perhaps because the application is not signed, or packed in a way that causes heuristic scans to alert.
Can the maintainers please consider white-listing and/or submitting a false positive report to Secure Age? Also, is there anything particular to the components or network behaviors in the harness that would be causing this so we can document for others so they're not concerned when building or installing.

Thanks for the awesome job on this tool!

[PerryLink]

误报的处置有标准流程——请补两样，我可以告诉你它落在哪一步

1. 请补两样

1. 检测名与文件名（SecureAge 报的是什么，例如 Trojan.* / Suspicious.*）⇒ 免费版杀软对"未签名/低流行度"文件误报很常见；
2. 文件哈希（sha256）⇒ 这是提交误报申诉时必需的东西（厂商按哈希入库）。

2. 标准处置三步（建议照这个提）

1. 向厂商提交误报申诉（SecureAge 有 false-positive 提交入口），附哈希 + 下载来源；
2. 请发布方提供校验和（若 release 页有 sha256 或签名，用户可先自证文件未被篡改）⇒ 这是用户侧最有力的自证手段；
3. 长期解法是代码签名（Windows 的 Authenticode）⇒ 它能显著降低此类误报。

3. 建议的诉求（写给发布方，可判定）

请在 release 中提供官方校验和（至少 sha256），并为 Windows 构建启用代码签名；同时把该文件的哈希提交给报毒厂商做误报申诉。

4. 一条边界

我没有该安装包，也无法复现杀软行为。⇒ 本条的价值在**"把误报变成可走流程"**；第 1 节两样齐了就能推进。

[RohitWaghire]

Thanks for this direction. Here are the information you have asked:

• Detection / vendor: Secure Age - Malicious

• Filename: dsh-latest-windows-x64.exe

• SHA-256: d61cd8882f8b8a1251144320493ad27920d15139503eba2465b9579eee720cfc

• Virus Total result: 1/50 vendors, with only Secure Age.

• Download source: DeepSeek harness Windows official download or release.

Virus Total report:

https://www.virustotal.com/gui/file/d61cd8882f8b8a1251144320493ad27920d15139503eba2465b9579eee720cfc/detection

Maintainers: can someone confirm the real SHA-256 for this release and if yes, submit it as false-positive to Secure Age?

Thanks again.

[PerryLink]

你给的材料已经足够提交误报了——而且不必等维护者

1. 你这份证据是"误报"的最强形态

你给的	为什么有力
厂商：SecureAge；文件名：dsh-latest-windows-x64.exe	指明是单一引擎的判定
SHA-256：d61cd888…720cfc	误报申诉按哈希入库，这是必需项
⭐ VirusTotal 1/50，且只有 SecureAge	50 引擎中仅 1 家报毒，这是"误报"最直接的统计证据
来源：官方下载/发布页	排除"用户拿到的是被篡改文件"这一解释

⇒ 建议把 VirusTotal 那句放在摘要第一句（"1/50，仅 SecureAge"）——它比任何描述都更能让厂商与读者判断。

2. ⇒ 不必等维护者：用户也可以提交误报

误报申诉通常对任何提交者开放（不需要是项目维护者）。⇒ 你现在就可以做：

1. 向 SecureAge 提交误报，附：哈希 + 文件名 + 官方下载来源 + VirusTotal 报告链接；
2. 提交时说明判定结果（"1/50 engines, SecureAge only"）；
3. 若厂商要求样本，附上你下载的文件（或让他们按哈希自行获取）。

⇒ 这条能今天就推进，而"等维护者确认哈希"会把它卡住。

3. 但"官方哈希"仍然值得要（#已知的长期解法）

你请维护者确认真实 SHA-256 是正确的诉求。⇒ 建议把它写成一条可执行的发布项：

请在 release 中提供官方校验和（至少 SHA-256），并在 Windows 构建上启用代码签名；同时把该文件的哈希提交给报毒厂商做误报申诉。

理由：有了官方公布的校验和，任何人都能自证"我拿到的文件与官方一致"——这才是"误报"能被普遍接受的依据；而只靠用户自己算的哈希，别人无法排除"你算的是另一个文件"。

4. 请补一样（让你自己的哈希可被复核）

说明你是怎么算出这个哈希的（例如 PowerShell 的 Get-FileHash -Algorithm SHA256 <文件>）。

⇒ 这一步成本几乎为零，但它让任何人都能对同一文件复算并得到同一结果。建议与 VirusTotal 链接并列写。

5. 一条边界

我没有该安装包，因此无法替你确认这个哈希对应的是官方发布物（那需要发布方公布校验和，或你从官方源重新下载后复算）。⇒ 我能确认的是：你给的这份材料在形态上已经构成一份完整的误报申诉（第 1 节的四项 + VT 链接）。

[RohitWaghire]

Thanks for the clarification.

I actually deleted the original .exe once I had tested it, so I no longer have the specific file that created the Virus Total result.

I'll retreive the Windows binary from DeepSeek's official page, compute its sha-256 hash with Power Shell, and check it against this reported value:

d61cd8882f8b8a1251144320493ad27920d15139503eba2465b9579eee720cfc

If the hash is the same I will upload that binary to Secure Age along with the Virus Total report and source of download. If the hash is different, then I will call it a different build rather than the same file.

I'll also still ask maintainers to provide a published official checksum of the binary, so that users can verify it for themselves.