Change Windows code signing provider to SSL.com

[jiangxianliang007]

This PR updates the Windows code signing process to use SSL.com as the signing provider.

Changes include:

Replacing the previous Windows code signing provider with SSL.com
Updating the signing configuration and related environment variables
Adjusting the CI workflow to support the SSL.com signing process

The goal is to ensure Windows builds can be signed successfully using the new certificate provider.

[Copilot]

Pull request overview

This PR migrates the Windows code-signing provider from DigiCert (KeyLocker / smctl) to SSL.com's eSigner CodeSignTool. It rewrites the electron-builder custom sign hook to invoke CodeSignTool.bat with SSL.com credentials, and reworks the release workflow to install Java, download/configure CodeSignTool, guard against missing credentials, and verify the resulting signature. Signing is gracefully skipped when credentials are absent (test builds), while the release workflow hard-fails if credentials are missing so releases can't be published unsigned.

Changes:

• Replace smctl/DigiCert signing in customSign.js with SSL.com CodeSignTool, skipping when SSL.com credentials are unset.
• Update package.yml to drop DigiCert setup steps and add Java setup, CodeSignTool download/config, a credential-presence gate, and a post-build Authenticode signature verification step.
• Introduce new SSL_COM_* secrets/env wiring in place of the old SM_* secrets.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
packages/neuron-wallet/scripts/customSign.js	Rewrites the electron-builder Windows sign hook to call SSL.com CodeSignTool; adds credential gating and documentation.
.github/workflows/package.yml	Removes DigiCert/smctl steps; adds credential check, Java setup, CodeSignTool download/config, SSL.com env wiring, and signature verification.

Notes for the author:

• customSign.js passes a MODE env var that CodeSignTool does not read (it configures itself from conf/code_sign_tool.properties), so this is dead/misleading code; actual sandbox/production selection is done by the workflow's properties-file swap.
• The CodeSignTool download is unpinned ("latest"), which is a reproducibility/supply-chain concern for a release-signing pipeline.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

packages/neuron-wallet/scripts/customSign.js:49

• Optional (robustness): each SSL.com credential is embedded into a single shell command string with hand-written double quotes, and execSync runs that string through cmd.exe. Because cmd.exe still processes " and %VAR% inside double-quoted arguments, a secret that contains a double quote or a %NAME% sequence matching an existing environment variable will corrupt the argument and cause signing to fail in a way that is hard to diagnose (secret values are masked in the logs). SSL.com system-generated passwords can contain such characters. Consider invoking the tool without a shell-parsed string (e.g. passing an argument array to cmd.exe /c CodeSignTool.bat ...) so the credentials are passed literally.

    `-username="${SSL_COM_USERNAME}"`,
    `-password="${SSL_COM_PASSWORD}"`,
    `-totp_secret="${SSL_COM_TOTP_SECRET}"`,
    `-input_file_path="${inputPath}"`,
    '-override=true',