Skip to content

[Windows] Sign arkcli release binaries for Smart App Control / WDAC compatibility #16

Description

@yiluyang111-coder

Summary

The Windows arkcli release binary is not Authenticode-signed. On Windows with Smart App Control enabled, Windows Code Integrity blocks the binary before any CLI command can run.

Microsoft does not provide a per-app bypass for Smart App Control. Asking users to disable this system-wide protection is therefore not an acceptable workaround. Please sign every Windows release binary with a trusted RSA-based code-signing certificate.

Environment

  • Windows x64, build 26200, display version 25H2
  • Smart App Control: enabled and enforced
  • Code Integrity policy: enforced for user-mode code
  • Installed package: @volcengine/ark-cli 1.0.13
  • Latest package also checked: @volcengine/ark-cli 1.0.15

Evidence

Both tested Windows binaries report Get-AuthenticodeSignature: NotSigned:

  • 1.0.13 SHA-256: EBF8A1BDECDBF96D5A5EB97C78699741B61C5DCEF1FA5B8CDAA9901F68F95629
  • 1.0.15 SHA-256: B2277006BE2408E938FB272A6CD48D468B166931A3E8C4D9B899785CAECBF47E

Windows Code Integrity records block events 3033 and 3077. The process is blocked before argument parsing, so commands such as arkcli --version, authentication status checks, usage queries, and plan queries cannot run.

The npm package downloads the Windows binary from the Volcengine CDN and verifies the SHA-256 listed in manifest.json, but hash verification does not establish a trusted Windows publisher identity and does not satisfy Smart App Control.

Reproduction

  1. Use Windows with Smart App Control enabled.
  2. Install @volcengine/ark-cli from npm, or download the Windows AMD64 asset from the official release.
  3. Run any arkcli command.
  4. Observe that Windows Code Integrity blocks the unsigned executable and records event 3033 or 3077.
  5. Run Get-AuthenticodeSignature against the downloaded binary; the result is NotSigned.

Expected result

The official Windows binary should run while Smart App Control remains enabled, with a valid and trusted publisher signature and no related Code Integrity block events.

Requested implementation

Please update the release pipeline to:

  1. Authenticode-sign every Windows AMD64 and ARM64 production binary with an RSA-based certificate whose chain is trusted by Windows.
  2. Use a SHA-256 file digest and a trusted RFC 3161 timestamp.
  3. Sign the final binary before calculating and publishing the SHA-256 in manifest.json.
  4. Publish the same signed artifact through the Volcengine CDN, npm installation flow, and GitHub Releases.
  5. Add a release CI gate that fails if Get-AuthenticodeSignature is not Valid, the signer chain is untrusted, or the signed asset hash differs from the manifest.
  6. Document the expected publisher name and a Windows signature-verification command.

Acceptance criteria

  • Get-AuthenticodeSignature <arkcli-windows-*.exe> returns Valid.
  • The signer uses an RSA-based certificate trusted by Windows Smart App Control.
  • arkcli --version runs with Smart App Control enabled.
  • A read-only command such as authentication status can run without Code Integrity event 3033 or 3077.
  • Windows AMD64 and ARM64 assets distributed by CDN, npm, and GitHub Releases are signed consistently.
  • Release CI verifies the signature, timestamp, and published SHA-256 for every Windows build.

References


中文摘要

Windows 版 arkcli 当前未进行 Authenticode 签名,在开启 Smart App Control 的 Windows 上会在命令执行前被 Code Integrity 拦截。微软不提供单程序例外,用户只能保留系统保护而无法使用 CLI,或整体关闭保护,两者不应由用户承担。

请为 Windows AMD64/ARM64 正式发布二进制增加受 Windows 信任链认可的 RSA 代码签名和可信时间戳;签名完成后再计算并发布 manifest.json 中的 SHA-256,并在发布 CI 中强制校验签名状态、证书链、时间戳和哈希一致性。CDN、npm 安装流程和 GitHub Releases 应分发同一份已签名产物。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions