Towards Trustworthy Systems: In the Near Future Every Piece of Code Will Be Signed By Its Creator

Towards Trustworthy Systems: In the Near Future Every Piece of Code Will Be Signed By Its Creator

So who owns code? Who created it? How trustworthy is the code creator?

We have grown up with a world where we signing our code using comments like this:

/***************************/
/* Bill's Network Code 1.0 */
/* Created 19 Jan 2019     */
/***************************/

But what credibility does that have?

Does it have any legal standing?

Why can’t we properly sign code with our sovereign identities, and prove that we are the author of code, or in signing our updates on code?

With code increasingly building our world, we thus need to make sure we understand who are the creators of code, and whether they are trustworthy. In a blockchain world, developers will then have sovereign identities and be able to sign their code updates on whichever system they use.

At present, GitHub is taking over our digital world, especially in its integration into cloud-based systems. Microsoft knows this, and bought GitHub for $7.9 billion. And so, within a few years, it is likely virtually everything in our Cloud will run through GitHub, and it will scale into virtually every part of our organisational infrastructures. This will drive scalability, version control, security and resilience.

Increasingly we setup our data and information systems by accessing GitHub and then downloading the code required to setup and configure our infrastructure. And updates can be tracked and easily rolled-back if we have problems.

And so SSH has become the king of the tools, as it protects the communication process involved in the scripting and updating of the code. With the setup of a public and a private key, we can then verify trusted entities when they connect and upload code. The loss of these special keys could cause disaster for many organisations:

But how do we make sure that we know that a given developer really did upload the code? Up to know we have relied on comments in code, and for login systems. But, what if we really wanted to prove that a given developer created a piece of code?

Well, we can sign our code updates with GPG keys. These a public and private key pair and in the format that PGP (Pretty Good Privacy) uses. Unfortunately, PGP has never really achieved adoption at scale, as the management of those keys is just too big a challenge in corporate environments. But the key generation method, and the signing process has found a home in GitHub.

Within GitHub we add our SSH public keys, and can also add our GPG keys:

The SSH public key is then used when we connect to GitHub, and where we prove that we know our private key. For the GPG keys — created with the GPG program — we enable the signing of code into the repository by running:

git config --global commit.gpgsign true

Every time we commit the code, any updates will be signed by the developer who changed the code. In this way we enhance the security of the code commitments as only a given developer will have the private key associated with the person. On the commitments we now see the verified signature from the developer [here]:

With the increasing focus on GitHub, there are many enhancements that can be applied, including using a YubiKey Neo to verify the signing. In this way we can make sure that a developer would have to insert their YubiKey into their development machine, before uploaded their commitment. GitHub would then reject any code update which was not properly signed by a trusted developer.

In a blockchain world, developers would have their own unique sovereign identity, and their code signing would be derived from the public key that they put onto the blockchain. All of their code would then be signed by their private key.

While many developers just go for the default of RSA keys, ECC methods can actually be more secure and provide for good levels of performance:

So, make sure you consider setting up code signing in your GitHub, as it must be one of the most trustworthy places in the whole of your infrastructures, and code signing brings in much higher levels of trust.

Conclusions

If you company has a GitHub, make sure you get your trusted entities to sign for their code updates. This will make the code much more trustworthy. As an end game, we can see our code going completely open source, and where updates will be signed onto blockchains. Only then we will have a completely trusted infrastructure. For now, it is GitHub that is King, and looking a bargain buy for Microsoft. In the future, we need to move code signing onto a blockchain and properly prove code creators. For our future world to be so dependent on GitHub will be a major risk that requires us to distribute its infrastructure.