I know that the Home Assistant approach has been focused on rapid feature development as opposed to stability/consistent functionality. There’s a good reason for all of this and I get it.
The problem is that many users aren’t interested in more updates, once things work the way they should. There is pressure to update the system often to the latest full version, for security reasons. These updates usually break things somewhere (could be an add-on, an integration, etc) and some users have more or less a steady state in their homes and just want things to work and do not care about more features.
I see this as a roadblock to wider adoption of HA because most average users do not care about being on the bleeding edge and do not want to update constantly - they just want to pair their devices and have things work, but they should not run software that is years old and might not have security updates.
The solution, I believe, is to make updates more modular. Let users do security updates (maybe things impacting web-facing portions of HA) and other critical things without updating the rest of the system. Features, integrations, etc could all be maintained and updated separately.
It would almost be like having a web front-end that updates often (to keep bad actors out and patch security vulnerabilities) and a back-end that stays stable. Think of it as upgrading your door locks on your house frequently to keep bad guys out, but not having to remodel and reorganize your whole house every time you do it.
It’s not feasible to support all (old) versions indefinitely – one has to decide how many versions back would be (security) supported.
Currently there are 12 “main” releases in a year → one strategy could be to support the last 12 releases (one year of security support).
Another strategy could be deciding which versions are LTS: Long Term Supported. For example, one release a year (let’s say “may”) would be a LTS → so people who want just security updates, would make big update once a year, and only security bigfix updates when needed. Or it could be 2 LTSs in a year. Or 3 LTSs a year with a year support. Etc.
Security support for older (not only the newest) releases would be a great start. I’d also love to see a bugfix support (for LTSs?) as well.
This thread contains many interesting points on the subject:
I kind of like the LTR/LTS approach kind of the way that Ubuntu or something works. Maybe one LTR per year and it’s supported with security fixes only for X number of years. If you want to be on the cutting edge, get one of the other releases.
I agree that supporting old software indefinitely isn’t feasible. But there should be a middle ground between that and forcing full upgrades just to get security refreshes.
Another approach (or an addition to this) might be to make things like integrations more modular similar to the way add-ons are. For example, recently there was a Tuya integration change, but I had to upgrade my entire system just for one integration upgrade. This broke several other add-ons which I also had to upgrade as a result. If users could just download new integrations the way they would download apps on an operating system, that would keep more users on LTS versions without forcing them to overhaul every time.
Nabu Casa is about a dozen people. Fewer than that deal with the Beta release and managing the updates. How in the heck do you think that could be pulled off.
Update if you want.
Don’t update if you don’t want to.
There have been specific security problems in the past that have been significantly announced, so watch for them.
Just if you are running a 5YO version of firmware, don’t ask for support until you update.
(Yes we had one this week like that…)
I don’t know. If they don’t happen often, than it’s great → but it still requires a feasible strategy to handle them when eventually they do happen.
What’s going to happen?
people who are “living on the edge” with always the latest version → they just install the update → nice.
people who like a bit of stability in their houses, who run an older version → will they be forced to update to the latest version to get the security update? or will HA somehow let them update the older version with just the security fix? how much older?
As you see from the second use case, I believe people should be able to stay “a bit behind” and still have a good strategy for handling security issues. I think we can agree that it’s in everyone’s best interest for the security issues to be fixed as soon as possible and that everyone (majority) using the software gets them as soon as possible.
I don’t think it is feasible to assume that:
everyone has to always run the latest version,
everyone who is “staying behind” would/could immediately upgrade to the latest version.
Another aspect – when it comes to the question of how often it happens – is: “how is it [the security issue] actually defined”?
We can all agree that a method to bypass login authentication would be. But is “XSS vulnerability” a “security issue”? IMHO: YES, of course (and I’m a web developer).
No matter if it happens often or rarely → security IMHO requires a good plan, strategy, documentation.
For the second point, if we had some kind of a LTS release and if security updates were non-breaking, you could basically put it on automatic and push out security updates to everyone (maybe with ability to opt-out if you prefer).
Even the tinkerers/frequent updaters would still be updated faster than if they do it on their own. As someone who updates a few times a year, it still requires planning on my part (backing up things, testing after the new update, upgrading add-ons, etc). I don’t exactly drop the rest of my life responsibilities and read release notes every time a new version comes out, so there’s still a considerable lag. I imagine many others are similar.
That would greatly increase security overall regardless of LTS/infrequent updates or people who update on every major release.
Just to note, NC has more than 40 employees at the moment! Around 30 of them are shown here (if you want to take a look):
But I’m all with you, I can’t see the point in splitting updates or go with other update cycles.
HA is evolved enough, to do updates as they’re rolled out, at least once a month. The times were HA was unstable or had many issues after an update are long gone.
Compared to a few years ago, there are significantly fewer issues, and a lot of them are mistakes in configuration or other errors that aren’t caused by the update itself.
At least that’s my impression, but that might be clouded by my own installation, that hadn’t had a hickup in more than a year (around 30 updates).
Even if updates do not break things “most of the time”, updates still require testing, they require reading the release notes, they require backups, they require upgrading add-ons, HACS components, reconfiguring integrations, retooling dashboards. Many people do not make time for that. Certainly not 12 times a year. Home automation is an unpaid hobby for us, not a full-time job.
Just a few months ago with 2023.11.1 there was a HUGE breaking change that screwed my whole configuration - the /config folder changed to /homeassistant. Completely ruined my AppDaemon configuration. Worse, it failed silently so I had a ton of services down for a few days before I even noticed.
Updates are still work. The “average Joe” users that HA Green will bring in - those people are simply not going to run updates often. So we leave them open to security issues.
I do wish the community would think of HA as more of an operating system with modular components where backwards/forwards compatibility is prioritized. Keep the OS patched/up to date; the rest of the nuts and bolts keep working the way they did before unless you decide to upgrade them to the latest and greatest.
You are exaggerating this. It normally takes 5-10 minutes a month.
I can remember two in the 6 years I have been using HA.
When they have happened they have been well communicated with alerts (this is part of default_config), blog posts, forum banners and topics, podcast segments and newsletter articles. So if the users somehow miss all of those there’s not much else we can do.
What is considered a “security issue” in these statistics?
Is a XSS, for example, considered a security issue? If not, I’d suggest reconsidering the definition (but the whole issue is for another topic of course) → it might make the difference (or not… hopefully not :)).
Actually @justinb01 proposed a good looking solution (something that “can be done”):
LTS versions are just not possible with an application like HA.
It is built on top of a lot of other software packages and protocols and HA needs to follow these.
You can not compare it to something like Ubuntu or the like.
Ubuntu can decide to put old packages into their distribution, because there is a way to upgrade them to the newest version if need be.
Ubuntu would quickly die if they only distributed it with a Python 3.11 and users could not upgrade it to 3.12.
If the same should work for HA, then all integrations should be modular, both internal and external developed ones, or the LTS version would stop fun tipning in mere weeks, if not days.
Don’t forget that HA is very proactive in moving to new versions of python. This in itself provides security updates as in newer versions of the base code should provide security in itself.
However you have to install the newer versions of you want to keep up with that.
I have always felt that the use of HAOS and addons makes updates harder for some, since any error or breaking change in addon update may appear as HA issue. Also some addons are not official I believe opening door for other inconsistencies.
Core + independent containers may ease many of these problems especially if you don’t update often. Not saying it is better, just that errors cause may be more obvious.
I can’t think of a time when update of HA container failed for me, but several times other containers I use have issues. I literally never backup before update HA because never had issues (overconfident maybe). I imagine if I use addons I would relate these problems to HA and not the separate software. I often see people mention issues with addons when upgrading as reason they dislike HA upgrade but this is technically not HA issue, it is addon issue.
It’s a fair question. This is something I deal with on a daily basis as my job is a linux admin. I’m familiar with choosing between LTS and rolling systems. I’ve also been using HA for about five years and have a quite complicated home setup.
I understand the desire by OP, but my preference would not to adopt this method. Or if it was adopted, I would stay with rolling updates.
My reasons:
Home Automation is an inherently unstable environment. Many updates to integrations happen only because the provider has changed or broken things. If you were security only, those integrations would stay broken. In the existing model, such things are almost always worked around and fixed within days or even hours and ready for the next rolling release.
HA Core updates have been pretty damned good over the past few years. The QA team is especially good, and the design team have managed some quite tricky migrations from yaml to ui well. I’ve let my docker HA install self-update every Sunday for years with few issues.
Out of scope. This is HOME Assistant. The commercial automation system, where “keep it exactly as it is please” is more essential, have their own closed ecosystems. (Although HA can be used in that environment, and if airgapped, no reason why it would need to be updated.) I believe most HA users are, by nature, fiddlers.
You split the userbase. Community support become even harder. Anyone asking for support on LTS will not find it from those on rolling releases because they can’t test, or that bug was fixed months before for everyone else.
And the biggest problem with LTS updates - when you do finally upgrade. Some of my biggest nightmares have been dealing with very out of date systems and distros where dozens of breaking changes have to be coped with at once, often with scattered or missing documentation. This can be overwhelming.
I think the biggest reason to do this with LTS support is professional installation. It is not for the current users of Home Assistant. Suppose HVAC companies want to get into home automation. They would sell a package that includes hardware and software that works when installed. They would not need nor want regular updates - it should work as they installed it. Regular maintenance could include annual updates. In the mean time security updates could be applied. To support this model a two year LTS would be needed.
I hope that Nabu Casa is thinking of supporting professional installations. Revenue from that could sustain Home Assistant for many years.
Exactly. HA is going to struggle to grow beyond the tinkerer community if users and installers have to upgrade 12 times a year and babysit YAML files every time.
HA/Nabu Casa team should be thinking about how to support non-tinkerer community if they want to grow revenue. I think this would be a step in the right direction.
HA developers have done a fantastic job and huge progress from where things were several years back (I’ve been on HA for about 5 years now) but like I mentioned above with the /homeassistant folder location, there are still significant and breaking changes happening often.
That is why my original suggestion was not really a LTS model per se, but a model where the web-facing (exposed) portion gets frequent and possibly even automatic updates, and the back-end can be stable and steady and won’t need to change. That way your pro installers and your set-and-forget mom and pops can just get their light switches or HVAC or whatever working and leave it the hell alone (without worrying about security vulnerabilities), and your tinkerers can stay on the cutting edge.
