digital lock unlocked

Code signing is important for proving the integrity and authenticity of software but can GPG secure the Software Industry?

Digital certificates issued by certificate authorities are generally used to perform this task, but as we know and mentioned in a few blogs, here and here, they have strong limitations, such as:

  • They can be stolen
  • They are coarse granular
  • Identities can be faked with look-alike companies
  • The issuing process is long and time-consuming
  • Owners can’t track what’s been signed with them
  • They are extremely expensive, both to get and to maintain e.g. renewals, etc.

Several software publishers, especially in the open source community, have adopted GPG as the only alternative to digital certificates for signing application binaries. (See the recent decision by Notepad++ to give up on digital certificates in favour of GPG.)

The main advantages of GPG are its accessibility (you don’t need a CA to verify who you are in order to get a signing key) and the fact that it’s free.

The Holes in GPG

But is GPG the solution able to secure the software industry? Unfortunately, the answer is no. And here are the reasons why:

  • Too technical: setting up GPG, whether on Mac, Linux or Windows, requires in-depth technical knowledge
  • Too cumbersome: in order to verify someone’s code, you need to import his/her key to your key ring and sign it. Then you have to do numerous checks to confirm the key corresponds to the person who declared said key (and by the way you can’t rely on the Keyserver for that). Then you have to import the code signature (if it’s been created and detached from the code). And finally, you can you check if the binary was actually signed by the person who is claiming to be the signer.
  • Granularity is too coarse: similar to digital certificates, GPG is also used only to sign releases for main products or repositories. They are not for any and all types of software assets. Their sphere of authenticity is limiting.
  • No fit with current engineering best practices (CICD and DevOps): GPG is generally used for signing developers’ code. Gits support GPG signatures for that reason. However, at the same time, because GPG verification requires multiple steps, you cannot streamline the verification process within a single, easy to use build script.
  • Web of Trust is impractical: it’s a nice concept but it doesn’t work. (Check out this scathing post here by Filippo Valtora on the subject.)
  • Identities are not certified: well known Richard Stallman even says in his personal blog here to not to trust the keys under his name on any keyserver.

GPG at the End of the Day

As I mentioned before, you need to triangulate information, which takes time and it’s still not 100% secure.

In the end, GPG does not really improve questionable situations any better than digital certificates do. The only advantage of GPG compared to digital certificates is that it’s free, but that’s only when you’re calculating the direct costs. If you count in the indirect costs of installing malicious code signed with GPG thinking it was secure, then the price goes up significantly.

Honestly, what were we to expect given that GPG, as well as digital certificates, was not born to sign code? Digital certificates were actually developed by Netscape to verify a domain and encrypt the information exchanged between clients and websites. Similarly, GPG was born to encrypt and sign email communication. Unfortunately for us, industry geniuses just decided to put a square peg technology into a problematic round hole of a different sort.

Solving the GPG Problem

To secure the software industry, a solution is needed that is designed specifically to address this problem. This is why vChain decided to develop CodeNotary, a one-step solution that guarantees your code is exactly how you left it.

CodeNotary gives you the ability to maintain a high-level view of all your code from the main release level on down to the infinitely granular level of components, scripts, and beyond. Not only is CodeNotary a proactive DevSecOps best practice, but the savings that mount from preventing scaled problems happening further down the production pipeline is one of those rare moments to breathe easy.

Sound too good to be true? Don’t take our word for it. Get a free trial and see for yourself. 

Sign-up Here

References