BUILD-11520 Migrate code-signing off deprecated digicert/ssm-code-signing

[SamirM-BE]

Why

code-signing/action.yml pinned digicert/ssm-code-signing@v1.2.1, which DigiCert has vendor-EOL'd:

• End-of-service: 2026-03-01
• End-of-life: 2026-05-01 (already past — this is overdue)

DigiCert steers users to DigiCert Binary Signing (digicert/code-signing-software-trust-action), which is maintained and runs on Node 24. Tracked as BUILD-11520 (surfaced in the BUILD-10781 audit).

What changed (code-signing/action.yml)

Swapped the tool-setup step to digicert/code-signing-software-trust-action@v1.2.1 (SHA-pinned) in its default (full) mode, which installs the Software Trust Manager client tools + smctl and generates the PKCS#11 provider config (simple-signing-mode would only install smctl, without the PKCS#11 module jsign needs, so it's intentionally left off).

Because the new action manages its own download / caching / PATH, the migration is more than a uses: swap:

Area	Before	After
smctl tool cache	bespoke gh-action_cache of /tmp/DigiCert One Signing Manager Tools/... + manual "add smctl to PATH" step	handled by the action (use-github-caching-service) — both removed
jsign cache	shared cache step	kept (jsign-only cache)
SM_* env + client cert	set after the DigiCert step	moved before it (the action needs them to generate the PKCS#11 config)
SMTOOLS_PATH output	hardcoded to the legacy install dir	derived from the action's PKCS11_CONFIG output; a lowercase pkcs11properties.cfg symlink is ensured there
inputs	jsign-version, force-download-tools	unchanged; force-download-tools now maps to the action's use-github-caching-service

Why SMTOOLS_PATH matters (consumer contract)

SonarSource/sonarlint-eclipse (the only consumer) signs via its pom.xml:

<providerArg>${env.SMTOOLS_PATH}/pkcs11properties.cfg</providerArg>

So SMTOOLS_PATH + a pkcs11properties.cfg at that path is a public output contract of this action. It is preserved here, so sonarlint-eclipse needs no change. A fail-fast guard + a verify-step check make a broken contract obvious in CI logs rather than silently breaking signing.

Acceptance criteria (BUILD-11520)

• Confirm the EOL date (EOS 2026-03-01, EOL 2026-05-01 per DigiCert docs)
• Evaluate the maintained alternative for input/output compatibility (see table above)
• Update ci-github-actions/code-signing/action.yml to the maintained action
• Smoke test against a downstream consumer that actually signs binaries (see Test plan)

Test plan

⚠️ The one thing this PR cannot fully prove on its own is that real Windows signing still works end-to-end, because the install path / config filename produced by the new action is inferred from its PKCS11_CONFIG output. This needs a signing run on the consumer.

1. CI on this PR: pre-commit (yamllint --strict + actionlint), shell specs, etc. validate structure. There is no signing in this repo's CI.
2. Real signing smoke test (required before merge): on a branch of sonarlint-eclipse, point the signing jobs at this branch:

   - uses: SonarSource/ci-github-actions/code-signing@feat/smarini/BUILD-11520-digicertBinarySigning

   Run the Build workflow on a job that signs Windows artifacts, then confirm:
   • the action's Verify tool installations step passes (smctl, jsign, and pkcs11properties.cfg under SMTOOLS_PATH all present),
   • the Maven jsign / SunPKCS11 signing step produces signed binaries,
   • smctl --version and the signing step logs show no Node 20 deprecation warning.
3. Run twice to confirm caching behaves (second run hits the new action's cache + the jsign cache).
4. After merge, move the v1 tag so sonarlint-eclipse@v1 consumers pick it up.

Risk / rollback

Low blast radius (single consumer). If signing regresses, revert this commit; the deprecated action still exists on the marketplace but is past EOL, so reverting is only a short-term measure.

[hashicorp-vault-sonar-prod]

BUILD-11520

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gitar-bot]

💡 Quality: Migration depends on unverified third-party action I/O contract

The migration assumes the new digicert/code-signing-software-trust-action@v1.2.1 (1) accepts an input named use-github-caching-service and (2) exposes an output named PKCS11_CONFIG. The entire SMTOOLS_PATH consumer contract is derived from steps.digicert-setup.outputs.PKCS11_CONFIG (line 63). If either name is wrong, the use-github-caching-service input would be silently ignored by Actions (composite inputs are not strictly validated against the called action), and PKCS11_CONFIG would be empty — the latter is at least caught by the fail-fast guard at lines 67-70. The PR description itself flags that real Windows signing cannot be proven here. Recommend confirming the exact input/output names against the action's action.yml before merge (the PR is correctly marked draft pending the downstream smoke test), and noting that an incorrect input name fails open (caching silently not toggled) rather than failing fast.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Edge Case: SMTOOLS_PATH symlink assumes config dir is writable

SMTOOLS_PATH is computed as dirname(PKCS11_CONFIG) and, when pkcs11properties.cfg is absent there, a symlink is created in that directory (lines 74-76). This assumes the directory the third-party action writes its PKCS#11 config into is owned/writable by the runner user. If the action places the config under a root-owned or read-only location, ln -sf will fail and abort the step. The previous implementation used a /tmp-based path that was always writable. Consider verifying the action's config location is user-writable, or fall back to creating the symlink/copy in a controlled directory and exporting that as SMTOOLS_PATH.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 2 findings

Migrates the code-signing action to the maintained DigiCert Binary Signing tool while preserving the SMTOOLS_PATH contract for downstream consumers. Verify the stability of the inferred PKCS11_CONFIG directory permissions and the third-party output contract via smoke testing.

💡 Quality: Migration depends on unverified third-party action I/O contract

📄 code-signing/action.yml:53-58

The migration assumes the new digicert/code-signing-software-trust-action@v1.2.1 (1) accepts an input named use-github-caching-service and (2) exposes an output named PKCS11_CONFIG. The entire SMTOOLS_PATH consumer contract is derived from steps.digicert-setup.outputs.PKCS11_CONFIG (line 63). If either name is wrong, the use-github-caching-service input would be silently ignored by Actions (composite inputs are not strictly validated against the called action), and PKCS11_CONFIG would be empty — the latter is at least caught by the fail-fast guard at lines 67-70. The PR description itself flags that real Windows signing cannot be proven here. Recommend confirming the exact input/output names against the action's action.yml before merge (the PR is correctly marked draft pending the downstream smoke test), and noting that an incorrect input name fails open (caching silently not toggled) rather than failing fast.

💡 Edge Case: SMTOOLS_PATH symlink assumes config dir is writable

📄 code-signing/action.yml:71-76

SMTOOLS_PATH is computed as dirname(PKCS11_CONFIG) and, when pkcs11properties.cfg is absent there, a symlink is created in that directory (lines 74-76). This assumes the directory the third-party action writes its PKCS#11 config into is owned/writable by the runner user. If the action places the config under a root-owned or read-only location, ln -sf will fail and abort the step. The previous implementation used a /tmp-based path that was always writable. Consider verifying the action's config location is user-writable, or fall back to creating the symlink/copy in a controlled directory and exporting that as SMTOOLS_PATH.

🤖 Prompt for agents

Code Review: Migrates the code-signing action to the maintained DigiCert Binary Signing tool while preserving the `SMTOOLS_PATH` contract for downstream consumers. Verify the stability of the inferred `PKCS11_CONFIG` directory permissions and the third-party output contract via smoke testing.

1. 💡 Quality: Migration depends on unverified third-party action I/O contract
   Files: code-signing/action.yml:53-58

   The migration assumes the new `digicert/code-signing-software-trust-action@v1.2.1` (1) accepts an input named `use-github-caching-service` and (2) exposes an output named `PKCS11_CONFIG`. The entire `SMTOOLS_PATH` consumer contract is derived from `steps.digicert-setup.outputs.PKCS11_CONFIG` (line 63). If either name is wrong, the `use-github-caching-service` input would be silently ignored by Actions (composite inputs are not strictly validated against the called action), and `PKCS11_CONFIG` would be empty — the latter is at least caught by the fail-fast guard at lines 67-70. The PR description itself flags that real Windows signing cannot be proven here. Recommend confirming the exact input/output names against the action's `action.yml` before merge (the PR is correctly marked draft pending the downstream smoke test), and noting that an incorrect *input* name fails open (caching silently not toggled) rather than failing fast.

2. 💡 Edge Case: SMTOOLS_PATH symlink assumes config dir is writable
   Files: code-signing/action.yml:71-76

   `SMTOOLS_PATH` is computed as `dirname(PKCS11_CONFIG)` and, when `pkcs11properties.cfg` is absent there, a symlink is created in that directory (lines 74-76). This assumes the directory the third-party action writes its PKCS#11 config into is owned/writable by the runner user. If the action places the config under a root-owned or read-only location, `ln -sf` will fail and abort the step. The previous implementation used a `/tmp`-based path that was always writable. Consider verifying the action's config location is user-writable, or fall back to creating the symlink/copy in a controlled directory and exporting that as `SMTOOLS_PATH`.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}