I'm building a tool and users will run it by downloading a binary. What I'm considering is good ways to secure this for the user. There's for me easy ways like "Recommend running this on a new temporary VM without internet access". I've added file hashes on recommendation but that's mainly theater.

Are there other ways to signal "yes, this binary is trustworthy" without making it open source so people could actually look?

Currently I'm only providing a linux version so there's no global code signing like for mac/win.

  • 12
    "linux only" and "closed source" is not exactly playing to your audience. For sure closed source applications can work on Linux, but you will probably face a more uphill battle than if you chose a different platform. Feb 19 at 18:06
  • 23
    Maybe it's just me, but if a download were advertised with "I recommend running this on a new temporary VM without internet access", it would not signal to me that the binary is trustworthy. Quite the contrary.
    – Heinzi
    Feb 20 at 6:20
  • 2
    One thing that decreases trust is requiring installer to be run as root. Surprisingly many closed source products for Linux do this.
    – jpa
    Feb 21 at 15:41

3 Answers 3


A hash only really gives assurance that the file you downloaded matches the one on the website, not who the author was. So a digital signature using something like GPG (with your key publicly available elsewhere for verification) would be much better than a hash, because it provides some assurance that the binary was signed by you. If your key is signed by other reputable people that would also help.

Beyond that, if you're unwilling to share the source code for people to examine and compile themselves, it's not really a question of how to get people to trust the binary - it's a question of how to get them to trust you. And that's a complicated question with lots of factors, including how well known you are, your reputation, whether you're anonymous or publicly linked to an individual/company, where you're from, etc.

But there's no simple answer, because if there was an easy way to make a binary look trustworthy then all the bad guys would do it too.

  • 1
    Another option is using trusted third-parties. If you e.g. use automated builds and releases from a platform like GitHub, people only need to trust you as the author and GitHub will ensure that the binary download is actually what you developed.
    – Falco
    Feb 19 at 12:34
  • 12
    I've not trusted a single binary released via github. Anyone can sign up and release whatever they please via github, there's zero guarantee it's safe. Feb 19 at 14:33
  • 1
    This is the idea behind Apple App Store. Since you implicitly trust Apple to write your OS, you can also trust them to vet third-party applications.
    – Barmar
    Feb 19 at 16:01
  • The main idea I think is A) make people trust whatever digital service they're pulling this executable from and B) make them trust the author. ie. Open source code in github fulfills A) if it is hosted on github (github is a well known website and unlikely to maliciously mess with repositories), and has lots of stars (lots of stars implies many people have reviewed and tested in theory) and B) if it has maintainers with a career, names that appears legitimate (so if they were to upload malicious code their social lives would be damaged), and many successful previous commits that have been safe Feb 21 at 6:31


Ask yourself: What checkboxes do you personally have to check off to trust a closed-source binary?

Do you have an answer? Great, now go do those things with your binary.

Increasing trust in a downloaded binary

Provide a checksum on your website so I know whether I'm downloading the right binary.

Have a way for people to publicly report bugs and respond to said bugs in a timely manner.

Have a well-written changelog and version history to show that this is an active project as opposed to something abandoned.

Are there other ways to signal "yes, this binary is trustworthy" without making it open source so people could actually look?

Have a well-written man page so I can confidently use the binary.

Your reputation needs to precede the binary. Either people need to trust the author or they trust the download counter and see mass adoption. Not having negative reviews helps too.

There have been plenty of sketchy things I've run on Windows. I didn't know/trust the author nor the binary but it promised functionality I wanted.

It's different if you're building something for commercial use as opposed to personal.

  • 3
    This. Either you gain the reputation with years of hard work and many references so people will trust you by default (the recommended way), or (better) open source and wait for people to see/trust the code. Or you employ social engineering tricks and lies like any advanced spammer ("exclusive - get it free only for next 1 hour", pay for fake reviews/stars/ads/SEO, promise naked celebrities, etc) to get people to download and run it (in which case the app better be malicious and data-stealing in the first place, or you've ruined your reputation forever for no hard monetary gains :-) Feb 19 at 16:17
  • @MatijaNalis OK, so option 3 looks most promising ... Feb 21 at 7:28

If your users are technical enough you could pack it in a signed package format. PGP has already been mentioned, but the PGP system is complicated and annoying for users who aren't already using it since it requires maintaining the network of trust.

For a one-off I suggest the SMIME/CMS/PKCS7 package format made available through the smime or cms command of the openssl command line app. It's almost always installed on a system.

The instructions you'd give would be something like 'Download this CA certificate and for every download run:'

openssl smime -verify -binary -inform pem -CAfile <myCA.pem> -in <message.smime> -out <message>

Effectively they'd have to willfully construct a new command to get the file without checking the signature and certificate against the CA.

PS. On further investigation CMS may be the most modern version of this command with proper algorithmic agility. I'm most familiar with the smime variant.

  • 2
    The instruction should perhaps explicitly tell the users to not store that single-purpose CA cert into the trusted root CA directory! -- It has happened in real life: "Dear customers, please all install this software that is needed to encrypt communication between two parts of our software via the localhost interface. You will see warning messages that it is dangerous to proceed, but please just hit OK to ignore. This will install a public key as root CA whereas the secret private key is hardcoded as plaintext only in our software that everybody can download" Feb 21 at 7:35
  • @HagenvonEitzen Could you share a reference for that? I'm curious. Feb 21 at 8:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .