Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look for code signing alternatives #185

Closed
fernandreu opened this issue Nov 11, 2021 · 0 comments · Fixed by #188
Closed

Look for code signing alternatives #185

fernandreu opened this issue Nov 11, 2021 · 0 comments · Fixed by #188
Assignees
Labels
development only This issue does not affect users, just the development process enhancement New feature or request

Comments

@fernandreu
Copy link
Owner

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:

  1. 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
  2. On every signed build, generate an ephemeral certificate, to be signed by the root one from the step above
  3. All the binaries will be signed using this ephemeral certificate
  4. The ephemeral certificate will be uploaded as an artifact of the build, without the private key (for obvious reasons)
  5. 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.

@fernandreu fernandreu added enhancement New feature or request development only This issue does not affect users, just the development process labels Nov 11, 2021
@fernandreu fernandreu self-assigned this Nov 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development only This issue does not affect users, just the development process enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant