This thread is about a future feature planned for Caddy: auto-update. This will be a thing, but exactly how is still up in the air.
The major browsers have been auto-updating for years. Web servers can do this even more seamlessly because they’re not visual applications, and they’re even more crucial to update because they define the limits of the security of a connection. It’s time for web servers and browsers to grow in harmony together as they each auto-update.
What we do know so far (these are basically non-negotiable):
Caddy will eventually have auto-updates.
They will be enabled by default.
They may be disabled, just like HTTPS can still be disabled. (Sad face)
Caddy will need to emit telemetry in order for this system to be effective/useful.
A comprehensive suite of tests will need to be in place.
Failed auto-updates will not be fatal; merely a log message.
What we don’t know:
The scope for auto-updates. What’s important enough to automatically update?
How to know that an update won’t break a site. (Then again, browsers don’t care, especially for security updates.)
How to roll back if something does go wrong after an update.
When these will be ready for testing.
My initial thoughts are that auto-updates will be limited to changes in cipher suites, curves, TLS versions, HTTP updates, etc. Bug fixes? Maybe. Probably?
There’s a tricky optimization problem here: I want to fix as much as possible with updates but change as little as possible. In other words, I don’t think we should auto-update every time there’s any new release out. Auto-updates should be triggered only for certain fundamental Web changes (or important security/bug fixes). And each build is going to be tailor-made for each auto-updating instance using our build server. So each instance of Caddy will need to be woke enough about its build configuration.
Thoughts? Feedback? This is a more casual thread, but eventually we’ll make an issue on GitHub that will be focused on actionable dev items to make this happen.
With whatever update server you run, you (and plugin maintainers) could tag releases as critical/default-autoupdate and allow people to specify something like updates (all|feature|important|critical), where:
All means all updates. Suite changes, bugfixes. Everything. Not the bleeding edge, per se, but a more stable version of that. If there’s a new version of anything released, we want it. Maybe this isn’t a great idea for build server performance reasons or perhaps we don’t want this at all without much heavier testing in place before releasing.
Important means updates that contain significant performance improvements or non-critical security fixes
Feature means updates that contain significant new features (i.e. 0.10 release)
Critical means updates that contain high-risk security vulnerability fixes.
Periodically (hourly? every 3 hours? daily? configurable?), Caddy will send a request to the update server with:
The update server will return a boolean that could be called needsUpdate that returns whether or not the requesting server needs to update.
A server needs to update if:
Fixes to the Caddy core have since been released which meet the updates directive’s severity level
Plugins have released updates (?)
If the server needs to update, the update server will query the build server to see if the build the requester needs is already cached. If not, it will kick off that build, cache it, and serve it to the requester (how?).
This will be amazing. If it means I can just leave my server running, and know that the answer at least to “am I safe?” is “as much as you can be”, then that would be a good thing already.
To be honest, even having it log the fact that an update is available would already increase the utility. At the moment, I get an email about changes, but if there is a specific log entry for it too, I can monitor it, alert it, and automatically put it into the maintenance queue.
I would second @JoshHarmon’s comments - it makes it match what I’m used to with system updates, with critical stuff we usually set it to “security+critical” (which I guess is really just critical), but it would be great for example if I could test a new feature version, and when I trust it, just change my Chef scripts to pop the config to all for a while and let it update my servers. It can then set it back to critical afterwards.
As a Docker user, I wonder how this auto updater will function inside a container. It would be detrimental to pull a Docker image tagged 0.9.5 and load it up only for Caddy to go “Nope, onwards to 0.10.1!” every single time you start the container again.
