Should your software update itself automatically? **YES!**
If you aren't convinced, we've previously [made the case for automatic software updates](https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers#why-automatic-updates) as a means of preventing yesterday's software vulnerabilities from being exploited today.
However, as [our previous article on the subject](https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers#outdated-software-risk) notes, implementing automatic software updates requires a nontrivial amount of engineering effort in order to be secure.
Our company has been hard at work for the past few years to diminish the effort required to achieve *secure automatic software updates* in the PHP community. Most of our efforts are reproducible and/or relevant to any other programming stack, although [PHP remains the first major programming language to decide to adopt modern cryptography in its standard library](https://dev.to/paragonie/php-72-the-first-programming-language-to-add-modern-cryptography-to-its-standard-library).
Let's explore how to use our existing work to build a secure automatic software update system, without having to do any of the heavy lifting.
# Simple and Secure Automatic Software Updates
How to Implement Secure Automatic Updates, the Easy Way
First, make sure your deliverables are [reproducible from the source code](https://reproducible-builds.org/). If you're working with scripting languages that are never compiled into binary code, this merely requires your software be open source.
Second, use an update framework (i.e [The Update Framework](https://theupdateframework.github.io/)) that enforces code signing. This means that your update files must be signed by a private key controlled only by you, but can be verified by anyone with your public key.
> If you don't understand what "private key" or "public key" means, [this page](https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-password-cryptography-decoded) is an approachable introduction to cryptography terms and concepts and will shed some light on the matter.
Finally, run a [Chronicle](https://paragonie.com/blog/2017/07/chronicle-will-make-you-question-need-for-blockchain-technology) instance. Every time you release an update, publish the new release information to your Chronicle. Make your code that interfaces with The Update Framework verify that the release you're seeing is also published in the Chronicle (or, especially for enterprise customers, their own replica of your Chronicle that resides on the corporate network).
That's it. **The Update Framework** (or a similar implementation relevant to your stack) and **Chronicle** are all you need (as far as tooling goes). Make your software open source, and your builds reproducible, and you'll drastically reduce your customer's attack surface in terms of both space *and* time.
Secure Automatic Software Updates in PHP
There isn't currently a PHP implementation of The Update Framework. If there's enough community interest, we may commit to building one in the future. However, that might not be necessary.
If you're developing modern PHP, you're almost certainly using Composer and Packagist. If not, it's [highly recommended that you learn it ASAP](http://www.phptherightway.com/#composer_and_packagist).
Earlier this year, I opened a proposal to the [Packagist team](https://github.com/composer/packagist/issues/797) to run their own Chronicle instance, which would be used to publish information about software releases in real time. We're working on other proposals to enforce signature validation and solve the Public Key Infrastructure (PKI) problems.
In other words: If you're using Composer, then in the near future this may already be a solved problem for you.
If you cannot wait for our work to be accepted and deployed in Composer, you'll have to either roll your own implementation or [hire Paragon Initiative Enterprises](https://paragonie.com/services) to build it for you. We've previously implemented secure automatic updates in [two](https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cryptography-powering-cms-airship) [different](https://paragonie.com/blog/2017/08/introducing-ward-web-application-realtime-defender-waf-ids-automatic-security-updates-for-php-software) products (one of them is Free Software). Refer to the implementation in CMS Airship if you need a starting point.
If your users won't have the Sodium extension available, look into [sodium_compat](https://github.com/paragonie/sodium_compat). This probably won't be a problem once everyone is running PHP 7.2 and newer.
Secure Automatic Updates for Embedded Devices and the Internet of Things (IoT)
Embedded development faces unique challenges and there hasn't been a lot of guidance on implementing secure automatic update protocols, especially for so-called "smart devices". Due to low memory or power usage requirements, it's often not feasible to just staple cryptography onto your product design without using up your entire power or memory budget.
For extremely constrained devices, [libhydrogen](https://github.com/jedisct1/libhydrogen) is an attractive option. It's very lightweight, and the current implementation uses only two primitives to provide a full-featured cryptography library: the Gimli permutation and Curve25519.
> Commercial support for libhydrogen is available from [Primulinus](https://primulinus.com).
The protocol designs that went into **The Update Framework** and **Chronicle** can be easily re-implemented using libhydrogen, but the Hydrogen version will not be compatible with the Sodium version. If a Hydrogen variant of Chronicle is desired, [get in touch with our team](https://paragonie.com/contact).