Proposal: Update SignToolSignRunner to always include /fd parameter, default to SHA256, and support SHA384/SHA512

[Kucha1122]

Proposal: Update SignToolSignRunner to always include /fd parameter, default to SHA256, and support SHA384/SHA512

Overview

This proposal suggests changes to the SignToolSignRunner to resolve issue #4298 and improve the SignToolSignSettings. The goals are:

1. Always emit the /fd (file digest) parameter for the signtool.exe sign command, as newer Windows SDK versions now require it.
2. Default to SHA256 when the user does not specify any digest algorithm.
3. Extend the SignToolDigestAlgorithm enumeration to support SHA384 and SHA512, giving users more control and aligning with modern security standards.

---

Background & Problem

As reported in #4298, starting with Windows SDK 10.0.20348.0, Microsoft's signtool.exe requires the /fd parameter to be explicitly provided. Failing to do so results in the following error:

SignTool Error: No file digest algorithm specified.

Currently, Cake's SignToolSignRunner includes this parameter only if DigestAlgorithm is set to Sha256. This is insufficient – users who don't set any algorithm (or set Sha1) get a broken build.

---

Proposed Solution

I propose modifying the SignToolSignRunner as follows:

1. Always add /fd to the signtool.exe command line, regardless of whether DigestAlgorithm is set. This matches Microsoft's updated requirement.

2. Make SHA256 the default – if DigestAlgorithm is null or not provided, the runner will internally default to Sha256 and emit /fd SHA256.

3. Extend the SignToolDigestAlgorithm enum to include:

   • Sha384
   • Sha512

   The current enum only offers Sha1 and Sha256.

Impact on Users

• Most users will see no breaking change – their signing tasks will simply start working without any modifications.
• Users who explicitly set DigestAlgorithm = Sha256 will continue to get the same behavior (/fd SHA256).
• Users who need Sha384 or Sha512 can now set those values and the runner will emit /fd SHA384 or /fd SHA512 accordingly.
• Users who need Sha1 will now also benefit: the runner will emit /fd SHA1 (currently, no /fd is emitted at all, causing an error).

---

Next Steps & Request for Feedback

I have already implemented these changes locally and am ready to prepare a pull request. Before I proceed, I would like to ask the Cake team:

1. Is this change desirable and aligned with the project's direction?
2. Are there any concerns about adding SHA384 and SHA512 to the SignToolDigestAlgorithm enum?
3. Would the Cake team accept a pull request that implements this proposal?

Thank you for your time and input!