[tech] Signing builds

[Luke Emmet]

On 15-Jan-2021 01:59, Mansfield wrote:
> I'm wrapping up work on a Gemini client and planning on producing builds
> for Linux/Darwin/Windows. (32-bit and 64-bit... which I think(?) is
> standard...)
>
> When I test the Windows binary executable there are several warning dialogs
> that pop up talking about how the exe hasn't been signed and is unknown and
> might be best to not let run. I think that Code Signing certificates and
> signing the binary are the generally recommended approach to overcome that.
>
> I looked into Code Signing certificates and I found some that seem like
> they'd work for the Windows builds (from the little that I know... all I
> need is something called a Code Signing certificate... I don't *think*
> there's any OS-specific aspect), but they're $100/yr. Not horrible, but
> certainly more than expected. In my ignorance it feels odd that there's
> nothing like LetsEncrypt for Code Signing certificates.
>
> So the question is this: If you were producing a stand-alone binary
> executable meant to run on Windows and you wanted to minimize the install
> friction (like not having the warnings described above), how would you
> approach that?

I went down a similar route for my own native windows gemini client. In 
my experience some anti-virus products can be quite aggressive to 
"protect" the end user from unknown apps as well as ones known to be 
malicious. Basically the anti-virus apps give an unknown app a score 
based on a number of factors, such as:

 ?- is it signed with a non-self-signed certificate

 ?- is the app "well known" - (size of existing user base)

 ?- does the app want to do anything "risky" (like access a server on an 
infrequently used obscure port, say 70 or 1965) or use privileged APIs

 ?- does the app include any libraries or source used by other malicious 
apps

So for something like a gemini client, quite a few of these can trigger 
warning flags.

> One solution: I could just hope that users would be willing and/or able to
> ignore the warnings and install it anyway. Keeps costs down... keeps build
> process simple. Might not have as much adoption as hoped.

Yes, why not start out like this to get some feedback, but eventually 
your users will complain that they cannot easily install it. Most end 
users will be uncomfortable with fishing an app out of quarantine and 
marking it as "safe" against the advice of their AV, even if it is a 
false positive.

So I think you'll need to go down the route of looking into getting a 
certificate at some point. It is somewhat frustrating to have to battle 
these self appointed gatekeepers, but...

> Another solution: Pay the yearly fee, sign the builds, avoid the warnings.
> (I'm also not sure how the certificate will verify I'm trustworthy when I'm
> not so certain I want any personally identifiable information to be shared
> with whoever will be running me through whatever process - I dream of
> something simple like a dns cname record to prove ownership and the cert
> then saying the builds were produced by the owner of the domain... or
> something...).
It's frustrating, but I think this is probably needed if you want 
adoption beyond a few early adopters. I can recommend Certum who have an 
"open source developer" certificate pack available for a not huge fee.
> Third option: On the side, I've also written a modified HTTP/HTML server to
> use a gemini client and make it super easy to browse Gemini space *without*
> installing a client, but I'm reluctant to have feature-parity between that
> browser-based client and this standalone binary client. I could just go
> with, "Install the unsigned client if you want and if you're uncomfortable
> with that feel free to use the browser-based one, but you're missing out if
> you don't install the standalone one".

Definitely get the users to come onto Gemini - it is quieter and calmer 
here :)

 ?- Luke