I have a couple of questions:
I have another question.
How long are you going to keep flogging this dead horse?
I’m not flogging a dead horse. I’m trying to make people aware of their bias. If people want HA to become a product that can be installed by “average users”, people should stop thinking as nerds.
re 1: many. maybe even most. Plus, your issue was that there was no easy way, but there is! And your second issue is, that HACS is not in core, but VSC is, ergo: use it!
re 2: all things core have auto-update. all things third part usually work for a long time without updates. And when you notice it stopped working: go to repo, copy & paste again
re 3: 90% of my HA is done via mobile. write on your mobile and then, you guessed it: copy&paste
But re 3 also: I too would love muuuuuch better mobile support for VSC. But the original devs don’t. So though luck 
I think you and I have very different images of the average user in mind. I know a lot of people that I’d love to see using HA. However, I don’t recommend it to them, because I know there are lots of hurdles they likely aren’t going to take. Like getting to know the concept of editing plain text files. Let alone use a tool like VS Code.
What do you mean by “VSC is in core”? I’m not aware of any text editing that’s integrated into HA that is even remotely as mature and productive as VS Code.
I don’t know about you, but I find the integrated text editor of HA horrible. It’s horrible on Desktop, and even more so on mobile. Whenever I’ve to edit a text file, I wait until I can do that from the comfort of my editor of choice, via the SMB share.
If the horse is dead, why is it stilla debate that is quite active and people apparently care a lot about?
No matter how many people are flogging the dead horse, it still wont make it go any faster.
Hello I am a new HA user, non-IT trained and an older generation. I have spent the last 18 months learning; I am blown away by the creativity of this open source project. I marvel at the width and depth of the contributions. HACS was my second integration and driven by a need to access a much wider group of contributions. Some of those contributions are emerging, some are changing, some are deleted or subsumed into other contributions. HACS provides a safe harbour for this wider non-core “ecosystem”. I was and remain grateful that the HA core team has allowed this two speed world to exist. It is richer and more interesting. I would very much oppose HACS changing …… leave it be …. It is doing a great job. We need to nurture inspiration.
HACS provides no safety, only convenience.
A safe harbour for the contributor. Or at least a lower hurdle to contribute. Certainly not safer for me as a user! I wonder whether I would ever be able to contribute! Too old and too late!; but I am very grateful for all the contributors.
Why did VSC come up again? There’s a 6 step installation guide for HACS and it doesn’t involve vsc.
Whether HACS is included in core or not this is still true for all the things you install from HACS. What’s the point?
Or are you referring to keeping vsc/ssh addon up to date? If so, you don’t have to. If having to leave the UI for an integration is a non-starter for you then just uninstall the addon after installing HACS.
So you’re too busy to follow the 6 step, 30 word instruction guide for HACS but not too busy to try and research a bunch of custom components? There are tons of WTHs around difficulty with HAs documentation and it’s still a step above what I’ve found in nearly all HACS components I’ve tried.
I don’t believe this is a real use case. If you want something from HACS the easiest part is getting HACS installed. Actually figuring out how to use something from HACS once it is installed is going to take longer then following that guide. And less likely to be smartphone ready since most custom integrations are yaml only and most custom UI components don’t have a GUI editor yet.
Even the ones I’ve found that are gui-ready often have pretty confusing GUIs. I don’t think I’ve ever managed to install and use a HACS component without combing it’s doc to figure out what is what. And often have to test things after that since they still don’t make sense.
The user guides are materialising on these forums. The definition of development in progress. Love it!
I’ve answered all (rhetoric) questions in the most recent addition from @CentralCommand before already.
I thought I would add a point that has perhaps not been considered. HA has a reputation to maintain.
If people want to install a bunch of custom components from unknown sources, that’s up to them. And in theory, they clicked an ‘I understand the risks’ button, so it’s on them.
But in the same way that some users confuse the lines between core, integrations, addons, custom components and HACS, if a problem occurred, many would confuse the same lines and assume that ‘Home Assistant caused it’.
A ‘problem’ with a rogue HACS integration could be as catastrophic as ‘disabled my door locks/alarm, pasted my camera feeds + GPS coordinates and passwords of all services to pastebin, then installed ransomware’. It might not even be a rogue developer, it could simply be a compromised github account.
Nobody wants this to happen, and most users probably expect that someone is acting in their interests to prevent this sort of thing. In this case it’s the core devs performing that role by thoroughly reviewing everything in HA core and not bundling HACS.
I think a user needs to consider why the integration they want is released as a HACS integration instead of within of HA core, and be happy with the reason. If that’s too much trouble, they shouldn’t install HACS. Making HACS a little bit difficult is a sensible barrier because it probably filters out all those who are unaware of (or unwilling to appreciate) the risks.
@dave_t_uk, I like the good perspective in your post.
I would be very cautious about assuming technical capability and risk management are aligned.
It could be said that if you install HACS using the current documented method of a curl pipe shell script without intercepting/downloading and reading the script pulled (and understanding it) before executing you have failed the risk management skills test already.
You could go a step further and say that curl pipe sh scripts are a security threat to HA in general. The lower the technical barrier to a very low level and a malicious person could take advantage of that.
HACS is a reasonably trusted source but we do rely on those maintaining it to make sure everything is still trustworthy.
A way around they could be for HA to make HACS an endorsed custom component (or something like that) and add an option in advanced setting to install HACS. That way the HA core can maintain the trusted install method but HACS can remain independent.
Possible another way to approach this whole thing is feature in Home Assistant with a setting to enable the use of custom components at all, manually or HACS loaded. This could be an advanced feature and have the necessary warnings and links to resources before being enabled. Might be a useful feature for debugging and reporting issues as well, turn off custom components.
But then where is the difference with the entire HA dependency chain ? HA, even without HACS, installs a ton of third party packages. You entirely trust the people behind projects like PyPi to maintain their packages free of malicious code. And there’s a ton of that in open source repositories like PyPi. It’s impossible for a small team of developers like the HA devs to audit every single third party package they pull in (and every package pulled in from these packages, etc). For every version. It’s all based on trust.
So it’s on only about HACS. It’s about everything in open source, including core HA. And sadly, FOSS supply chain attacks are massively on the rise.
Not much as you have pointed out. The main point of difference would be Nabu Casa having a purpose and paid developers. Unlikely they will be able to review everything but far less likely sonwthing would be missed.
Sometime it can be as simple as forgetting to update payment details for domain name renewal. Hypothetical example, Imagine if HACS.xyz lapsed (I assume this is owned by the developer and not Nabu Casa) and a malicious third party took it over with malicious intent. How could we really able stop people from using it.
This WTH has got me thinking and now I am a little concerned about HA transitioning from nerd to general user application becoming a target for malicious attacks. And I think the curl pipe sh type of vector will be the most likely way.
Indeed. As I’ve said before: I think the way it is setup currently is a form of “security through obscurity.”
I think HA can make the installation of any third party plug-in (not just HACS) easier, while at the same time improving security and lowering the risk that HA is blamed for a failure in a third party plug-in:
I’m not saying this is easy and I’m not expecting this to be implemented next week. But I think some vision is needed on how to replace the current situation with one that is both more secure and user friendly.
I agree with this in theory, with a but sometimes included integrations ( ones installed through integrations) become broke and cause issues. Most are caught during beta, but not all. The ASUS integration has been broken for some time while the beta of it works fine. As an open source project it is the developers that make sure that things work.
I could be wrong (but I don’t think I am) but the HACS dev doesn’t do anything at all with code review to make sure anything is “trustworthy”.
It is totally a “use it at your own risk” situation.
I’ve got some stuff in HACS and as far as I know there was never any code review. I just forked the HACS repo and added my repos to the list of included repos once the format was verified it was merged into HACS.