The old signtool has been retired. This moves over to the new sign tool.
This offers two significant security improvements:
we can use a Managed Identity instead of the old client credentials flow to authenticate with Azure Key Vault
the critical cryptographic step now happens inside Azure Key Vault, not on the build agent
Both of these improvements remove the need for the build agent to be in possession of a critical secret.
Because of 1, we no longer need to supply the build agent with a Client Secret. That Client Secret was critical because if it had ever been leaked, they would effectively have stolen the build agent's identity, and would have been able to ask the Key Vault to perform any operation that the our build process is allowed to do.
Because of 2, if the build process is compromised (which could happen if the project maintainers unwittingly merged a malicious PR—something that could easily happen if the malicious intent were concealed behind an apparently useful change) it is no longer possible to exfiltrate the signing key. The old signtool downloaded the private key of the code signing certificate and generated the signature itself, creating a risk that malicious code running during the build might be able to obtain that key. (We ran code signing as a separate, simple step to minimize this risk, but it was never ideal that such a critical key ended up in plain text on a build agent, even if only briefly.) Now, Azure Key Vault performs the crucial cryptographic operation at the heart of code signing, meaning that the private key now never needs to leave the Azure Key Vault. This is a significantly more secure design because it removes any possibility that the code signing private key might be retrieved, which would have enabled whoever retrieved it to generate signatures from any computer.
We need to remain vigilant of course. Azure Key Vault will still sign whatever our build process asks it to sign, so it is vitally important to make sure that the code signing build step only submits for signature the components we intend to sign.
The old
signtoolhas been retired. This moves over to the newsigntool.This offers two significant security improvements:
Both of these improvements remove the need for the build agent to be in possession of a critical secret.
Because of 1, we no longer need to supply the build agent with a Client Secret. That Client Secret was critical because if it had ever been leaked, they would effectively have stolen the build agent's identity, and would have been able to ask the Key Vault to perform any operation that the our build process is allowed to do.
Because of 2, if the build process is compromised (which could happen if the project maintainers unwittingly merged a malicious PR—something that could easily happen if the malicious intent were concealed behind an apparently useful change) it is no longer possible to exfiltrate the signing key. The old
signtooldownloaded the private key of the code signing certificate and generated the signature itself, creating a risk that malicious code running during the build might be able to obtain that key. (We ran code signing as a separate, simple step to minimize this risk, but it was never ideal that such a critical key ended up in plain text on a build agent, even if only briefly.) Now, Azure Key Vault performs the crucial cryptographic operation at the heart of code signing, meaning that the private key now never needs to leave the Azure Key Vault. This is a significantly more secure design because it removes any possibility that the code signing private key might be retrieved, which would have enabled whoever retrieved it to generate signatures from any computer.We need to remain vigilant of course. Azure Key Vault will still sign whatever our build process asks it to sign, so it is vitally important to make sure that the code signing build step only submits for signature the components we intend to sign.