The code signing certificate being used to sign this tool is about to expire, so it's time to look for alternatives.
Simply put, all certificate authorities out there either cost too much for open source projects or their solutions aren't very automation friendly. As an example, the build so far relied on a pipeline agent running on my machine, where a cryptographic app was running. This app requires authentication every two hours or so, via my phone. Other cheap solutions typically have similar limitations which make them incompatible with a CI pipeline. The sigstore project looks promising but it isn't quite there yet when it comes to signing Windows applications (see this). Due to this, I doubt the solution I'll adopt will involve a paid code signing certificate from a trusted certificate authority.
This is roughly the alternative I have in mind:
Generate a root self-signed certificate whose private key will be stored in Azure Pipelines as a secret. I will probably put the public key somewhere visible on GitHub / Azure Pipelines
On every signed build, generate an ephemeral certificate, to be signed by the root one from the step above
All the binaries will be signed using this ephemeral certificate
The ephemeral certificate will be uploaded as an artifact of the build, without the private key (for obvious reasons)
The ephemeral certificate will be deleted from the pipeline agent, just in case it could be accessed by subsequent builds by accident
This alternative should hopefully be suitable for everyone. Users who don't have too many security concerns when using this tool can continue to use it without any additional burden. Users / sysadmins who do worry about security can check that the certificate used to sign the binaries uses a root certificate that matches the one from step 1 above. Alternatively, they could check that the binaries were signed using the exact same ephemeral certificate uploaded to Azure Pipelines. Nobody should be able to forge the same ephemeral certificate. Nobody except myself (with a bit of work); however, this is no different from today. Anybody who possess a code signing certificate could modify a tool maliciously, re-sign it and upload it in place of the original. When you trust a certificate, you are trusting that the person in hold of it isn't going to do anything malicious like that (which I won't!).
Hence, I think this solution should be suitable for almost everyone... except Microsoft SmartScreen. I am pretty sure the tool will be flagged as a security risk there. However, that is not too different from what some people are still seeing. Especially for relatively new builds, since these weren't downloaded enough yet. In this sense, using a properly signed certificate does not change the picture by much.
The code signing certificate being used to sign this tool is about to expire, so it's time to look for alternatives.
Simply put, all certificate authorities out there either cost too much for open source projects or their solutions aren't very automation friendly. As an example, the build so far relied on a pipeline agent running on my machine, where a cryptographic app was running. This app requires authentication every two hours or so, via my phone. Other cheap solutions typically have similar limitations which make them incompatible with a CI pipeline. The sigstore project looks promising but it isn't quite there yet when it comes to signing Windows applications (see this). Due to this, I doubt the solution I'll adopt will involve a paid code signing certificate from a trusted certificate authority.
This is roughly the alternative I have in mind:
This alternative should hopefully be suitable for everyone. Users who don't have too many security concerns when using this tool can continue to use it without any additional burden. Users / sysadmins who do worry about security can check that the certificate used to sign the binaries uses a root certificate that matches the one from step 1 above. Alternatively, they could check that the binaries were signed using the exact same ephemeral certificate uploaded to Azure Pipelines. Nobody should be able to forge the same ephemeral certificate. Nobody except myself (with a bit of work); however, this is no different from today. Anybody who possess a code signing certificate could modify a tool maliciously, re-sign it and upload it in place of the original. When you trust a certificate, you are trusting that the person in hold of it isn't going to do anything malicious like that (which I won't!).
Hence, I think this solution should be suitable for almost everyone... except Microsoft SmartScreen. I am pretty sure the tool will be flagged as a security risk there. However, that is not too different from what some people are still seeing. Especially for relatively new builds, since these weren't downloaded enough yet. In this sense, using a properly signed certificate does not change the picture by much.