Please digitally sign installer and application binaries

[cody-somerville]

Please digitally sign the Windows installer and application binaries.

A digitally signed installer and application binaries assures users that the software has not been tampered with since it was signed and improves the user installation experience by increasing trust and reducing likelihood of being blocked/warned by Windows Defender SmartScreen.

[ShreyasZare]

Thanks for the post. The code signing certs are too expensive which is why the binaries are not signed currently. Will try to get it done in future once its feasible.

[thetredev]

ChrisTitusTech (who you might know from YouTube) distributes unsigned binaries for free on GitHub (https://github.com/ChrisTitusTech/winutil), but also distributes signed binaries for a price on his website, to at least have a chance to nullify the costs of certification. Maybe you can do the same? Just a thought.

[ShreyasZare]

ChrisTitusTech (who you might know from YouTube) distributes unsigned binaries for free on GitHub (https://github.com/ChrisTitusTech/winutil), but also distributes signed binaries for a price on his website, to at least have a chance to nullify the costs of certification. Maybe you can do the same? Just a thought.

Thanks for the suggestion. I am not sure users would appreciate such a differentiation. Will think on this for a while though.

[cody-somerville]

Would distribution via Windows app store be an option? They would provide signing and only cost would be a $99 one time registration fee. This would only work if can be packaged as msix.

[thetredev]

@ShreyasZare yeah I don't think many people will buy it in the end or attract more people in general imo.

[ShreyasZare]

Would distribution via Windows app store be an option? They would provide signing and only cost would be a $99 one time registration fee. This would only work if can be packaged as msix.

Thanks for the suggestion. Will evaluate that option once.

[thegranddesign]

I think a good first pass would be to simply have a .asc file alongside the binary (or tar.gz) that is signed with your private GPG key. Then you would release your public key. This would be free and automatable.

[scheibling]

I actually do download and sign the Windows binaries regularily since I and a few friends use them at home, and I have access to a bunch of code signing certificates through work.

I'd be more than happy to have a look at setting up a public workflow for building & signing if you'd like, we've started doing this for multiple open-source projects in the last couple of months through OSSign

[ShreyasZare]

@scheibling Thanks for the comment. Can you describe how does OSSign work? Do they provide the certs directly to the developers or does the project needs to be build at their end?

[scheibling]

@ShreyasZare The way we do it is by signing open source projects with one of our company certificates, meaning the signing itself needs to happen on our end and we have some requirements around building the project in public from verifiable sources.

So generally there are 3 categories of signing workflows we can use, which one is chosen is pretty much up to you:

Manual Periodic Signing This basically means we, on request or every X weeks/months, fetch the built binaries from the repository, sign them and either publish them or send them back to you to publish on your end. This has the requirement of the build happening in public so that we can verify what's actually in the compiled binaries.

Semi-automatic (Signing only) This means the binary is built (in public, Github Actions or equivalent) on your end, and the resulting binaries are submitted, manually approved and then signed. The requirement here is that the build process happen in public, transparently so that we (and the end-user) can follow the build path from code to signed binary so there's no question of authenticity.

Semi-automatic (Build + Sign) This is more or less the same as the previous one, except we run the release builds on our end. We normally create a fork of the repository and setup a pipeline based on the original one that directly fetches the code from your repository, runs the build and creates the executables. This process also always happens in public on Github Actions.

For deployment/publishing it's more flexible, we can do anything from email to uploading them to a blob storage or publishing them for download on our side, whichever works best for you.

[ShreyasZare]

@scheibling Thanks for the detailed response. I am afraid that none of these workflows are feasible for me.

[scheibling]

No worries, feel free to reach out to [email protected] if we can help you at some point or if you just want advice :-)

We can customize a fair bit of the process when signing with our certificate, as long as the two main requirements (publicly verifiable build, signing on our side) are fulfilled. There are also options for dual signatures (selfsigned on your side, then our trusted cert). If you have a registered company, foundation or non-profit we have some other options that would mean that we can get you (sponsor) your own certificate, otherwise for individual developers Certum and Azure Trusted Signing are pretty much the only options at the moment.

(And an off-topic footnote - A genuine thank you for all of your work on this. Helped another friend set it up this week, it just works and is an absolute pleasure to use compared to a lot of similar software.)

[ShreyasZare]

@scheibling Thanks. I understand that the constraints are in place to prevent abuse. I am not sure about it though but will evaluate this option.

(And an off-topic footnote - A genuine thank you for all of your work on this. Helped another friend set it up this week, it just works and is an absolute pleasure to use compared to a lot of similar software.)

Thanks for the compliments :)