Yep, that’s correct. Ludeeus may skim the repo when first added, not sure. But it’s not a full code review and after the initial add updates are fully automated. If the developer of a HACS component decided to push an update that turned it into malware, nothing stops them. Users of that component are expected to audit the code and flag it if they have evidence it is doing something nefarious.
Essentially if you use a component from HACS the only one keeping your system safe is you.
I was referring to HACS itself being compromised in that context. Pick you method, phishing, domain squatting etc. HACS itself has become so popular that it shows up in many guides.
The security/stability component’s that HACS installs is a separate matter.
I agree we need custom components. I need them as in countries outside of the USA and Europe this is often the only way to get some devices to work.
HACS being part of the default HA release does not mean that the integrations/frontend/etc things that are listed to be installed are blessed by HA. There is a distinction. I think HA could include HACS without opening that door…especially with the right UI messaging and perhaps even a setting that you have to use to turn on HACS visibility. There could even be a new “default” HACS catalog of things that HA has “blessed” as coming soon integrations that are being worked on to be integrated as official plugins.
In reality, installing HACS is easy. What is a pain is having to manage updating all sorts of packages through HACS on their update schedule since there is no “auto update” non-breaking releases. This becomes more of an issue the more HA installations you help manage (I am at 3 right now, but could easily be at 4 or 5 for family members).
In my opinion curl pipe scripts are a security risk to everything in general.
I don’t know details of the case you referred to but if sufficient tests are included for an integration, it doesn’t break on its own as HA doesn’t release with failing tests. But if the cloud API changes it can break. Then it’s a matter of how quickly an update can get put into HA core. HACS is faster due to no review requirement and no release cycle limitations.
Probably you don’t realize how thorough the checking already is. Each dependency is version pinned, and when a library is updated, the devs request a link to the diff between e.g. 1.2.1 and 1.2.2 of the library, which has to be reviewed before the PR is merged. So it’s not impossible, and it does happen. But it is time consuming, (IMHO for good reason).
It’s possible you misunderstand what is meant by API in this case. A HACS or custom integration is directly interacting with the HA core. It can access the other objects, and delete them, or create new APIs. It’s more of a shared object than an API. You really must trust this code and I think an automated test for ‘proper use’ would be too vast to be feasible.
This closest thing to this is add-ons, which run in a sandbox (docker container) already. But this is quite complex and I expect significantly more of a challenge to contributors than the usual HACS creation route (which I’m guessing often starts with copying and modifying an existing integration).
This is exactly the existing process for creating a core integration.
It sounds like you are saying that custom components are only needed because of things that aren’t in HA core. So if they were added to HA core, then that HACS integration wouldn’t be needed.
My impression is that some integrations are in HACS rather than core because contributors don’t like the review delay, requirement for UI setup, test coverage, style compliance, documentation etc. But all of those things are what makes an addition to HA more reliable, secure and maintainable. So as I stated before, if a user chooses to use a HACS integration, they need to be happy with the reasons why it’s in HACS and not core.
–
I have no objections to HACS. My only dislike is that having some integrations in HACS might reduce the urgency of adding them to core. But it is a good proving ground and a good starting point.
My overall view: if HA Core is insufficient for some users, we should focus on expanding the capability of HA core, not focus on making HACS easier.
I am referring to the ASUSWRT integration. It broke during beta and it is still broke. The author released a beta that works but something in his code is still not approved.
Uh huh. HA core alone, as basic as it gets, without Docker and HAOS (Buildroot) and their thousands of shared libraries, has over 150 Python packages. So they’re reviewing every source change to every single package everytime they bump the version (which is like, every month) ? What about the buildchain ? Is rustc / cargo (a lot of packages are build with this now) audited ? Who builds the wheels for common packages ? Are these binaries audited to make sure there aren’t code injections ? And once we go into HAOS things get really fun. Is Docker audited ? Do they have the highly specialist knowledge require to review the cryptography and oauth modules ? What about the entire buildroot environment with its thousands of dependencies ? Do they review every diff for every dependency when they update HAOS ?
There are entire companies that do open source code review and auditing services, like Black Duck. These companies have hundreds or even thousands of staff doing nothing but auditing, day in and day out. And even they can only small subparts of a large ecosystem. So you’re saying the 17 employees of Nabu Casa can do all this, not only for every single release every month, but they even find time to write and update HA ? Wow 
Believing that is very naive at best, dangerous at worst. This isn’t something to blame the developers for either. It’s just impossible to audit and review an entire software ecosystem you build upon, unless maybe you’re a state actor that pours billions into a highly controlled closed system. Not even GAFAM type companies do it. Home assistant has been more or less spared by supply chain attacks as of yet (as far as we know), simply because it’s a small niche product. But at the rate they bump dependencies and the rate new core integrations are added, I’m afraid it’s only a matter of time, even just as a collateral damage.
Well that’s what I do when I review version bump PRs (not just Nabu Casa employees do this).
There are a lot (4-5 ish per day). And a link to assist upstream review is specifically requested if the submitter forgets it e.g. this one from yesterday.
I’m not saying that HA audits every part of everything. Just that version bumps are not automatic, and that if something new + bad got into HA Core it would be via a PR review that missed it.
Well I would hope they aren’t. These kind of version reviews are needed for one single thing: compatibility and avoiding breakage and bugs. You’re not going to find malicious stuff that way, unless you stumble over it by accident and/or it’s really badly hidden.
And sadly that’s exactly what you would have to do to catch malicious stuff: review the entire supply chain, methodologically, dependency by dependency. And not only your direct dependencies. Everything. And not only the parts committed and in the diffs and changelogs. The binary builds too. The minified and uglified ones. The conveniently prebuilt modules and libs. The stuff your stuff pulls from pip and npm. Everything.
And you need to fully control the supply chain yourself. Your code installs things from PIP while you start it (and HA does tons) ? Then you’re already done and wide open to supply chain attacks and there’s nothing you can do about it.
I understand that the developers isnt fond of this possibility, but on the other hand; one of the strenghts of HA is exactly the plethora of supported devices.
Isnt this problem a lot like what the programmers of windows or android must be dealing with: They have to create a stable system which at the same time is open for a pletora of devices.
Maybe it isnt a question of moving the integrations closer to the core as such, but more a question of streamlining the User Interface? Isnt a great system, exactly a system in balance between developers and UI designers?
Hi. I’m new to Ha and was wondering if I should use HACS or not. There are a few cool features like animated backgrounds I would like to use. I see a lot of remarks that HACS is not safe and unstable. If I install HACS and don’t use any other installs with that impact a lot. And if I install something from HACS and it’s unstable and I remove it will my install be stable again.
Thanks in advance for the info.
I found that there are so many integrations and mods on HACS that I it is difficult not to add HACS. For the last two years I have not had any problems
Except that Microsoft and Google put hundreds of millions into doing this.
It’s not that installing HACS or any of the plug-ins it offers will make your HA install unstable now. The “problem” is that there is no quality control on anything that is offered via HACS. So no one can give you any guarantees. That said: the core HA code does have quality control to some degree. But formally speaking, you won’t get any guarantees on that software either.
Thanks for the info. Think I will create a backup before HACS so I can always go back to without. But people saying they runt] it for two years without issues convinced me to do it. Which version can I use best. I. See 3. So/supervised, container and core
I found this whole discussion very interesting. One thought I had a couple of times you also just touched on:
HACS would probably benefits from usage statistics and a rating system. It would be incredibly helpful to know how many users previously installed an integration and whether they have anything good to say about it. Just as any other “add-on” store of this world.
The “problem” is that there is no quality control on anything that is offered via HACS.
Gotta correct you there. All of these components are available on GitHub, merely aggregated by HACS. It’s not HACSs responsibility to “quality control” them. An ecosystem like the AppStore has payed reviewers, in the open source world I would see the community itself in the responsibility to provide feedback
I am also a new HA user and have exactly the same questions.
On the one had, I don’t want to install HACS if (or the applications available under it) makes my HA instal unstable or vulnerable. It has taken me too long as it is to get to the point I am
On the other hand I would love apps like music assistant and better spotify and more fun GUI’s etc
I’m very tempted…watching some of these cool youtubes
So what to do?
I just wish the HA moderators (or whoever they are) would take a look at which apps are being downloaded via HACS and simply place them directly (and officially) in HA.
Are they monitoring this and migrating all of the popular applications?
They could start with music assistant
Please!
That looks awesome - as the current media panel and it’s operation is really old…
Just MO
Well, I personally don’t think this is a problem at all! That’s why I put it in quotes. Earlier in this discussion, this was stated to be a problem, and this was the main argument why people opposed making HACS (or similar functionality) part of HA core.
I’m afraid that’s not going to happen. As other made quite clear earlier in this long thread: the developers of HA are quite busy developing HA and don’t have the time nor the interest to review the massive amount of plug-ins that is offered via HACS.
So, as with all open source software, you’re on your own. There simply is no one that can give you any guarantee. You have to make your own decisions about whether or not any software component is trustworthy. This goes for HA itself, for HACS and for all the components that are offered through HACS.
That said, I’ve learned that 44% of the HA users that have telemetry enabled, have HACS installed. I have it myself too. I haven’t heard any story about HACS or any plugin offered via HACS breaking stuff so far. But that’s only anecdotal proof…
It’s really not anywhere near that simple.
custom things aren’t bound by the same code rules as the built-in stuff is. So even if there was a desire to implement something as built-in then the HA devs likely couldn’t just cut & paste it into HA as an integration. It’s likely that the integration would need to be refactored before it would be accepted as a built-in integration. It’s usually the reason why the custom thing developer didn’t submit it to be added to core in the first place - the requirements can be pretty daunting.
And the original dev completely loses control over their integration at that point as well. They can’t make any changes to the newly built-in integration without the permission of the main HA devs.
And you need a dev to volunteer to be the maintainer of the integration after it gets added to HA.
This sometimes also causes a problem. Two releases ago the ASUSWRT built in integration stopped working where the beta version installed via HACS works fine. I can’t tell if it is the author’s issue or the HA team not approving a fix but the fix is stuck somewhere.