There’s some new logic to log (and prevent?) “request[s] and block commonly known exploit attempts”
I imagine someone found a custom_component out there acting in bad faith. We should wait for their official update; so far the HA team has handled these well imo and I appreciate this warning going up while they investigate further.
That is my standard procedure but I’m currently away from home so reluctant to risk the update. On top of everything else HA waters my garden and it’s hot in Perth this week!
4 Likes
Tinkerer
(aka DubhAd on GitHub)
Split this topic
21
To update Home Assistant, click on the Supervisor menu item
Do you mean Hass.io? I’m so confused. There’s a big issue with the naming of different parts of this project that needs to be resolved. The name “Home Assistant” is ambiguous. It can refer to the core project or to the entire distribution. The main web site is not perfectly clear about that too. A first-time visitor may think that they need a Raspberry Pi to use Home Assistant. In reality there are many different distributions that include different components and operate slightly differently. For example, I use a Home Assistant docker container on my NAS that doesn’t have a supervisor.
My Supervisor menu isn’t showing any available updates. Is there a way to force the check? I already followed directions to click the Reload on the System tab to no avail.
I don’t know what it is about my setup, but at times I don’t get notifications for a week or two. The only way I can reliably force the notification to appear is to reboot the host, which is a rather heavy-handed for my liking.
While “disable all your custom components” is prudent until the risk is analysed, “all custom components run at your own risk” does not work for me as a security posture.
Moving forward can we please get some clarity from the developers over exactly what reach into the home assistant environment, config files etc a custom component (not an add on) has and where it’s restricted?
Doesn’t this functionality already exist? Add-ons for one have separate config files. Integrations can be configured in a separate yaml file. Name the file integration_name.yaml then add
integration_name: !include integration_name.yaml
in config.yaml.
Or am I miss understanding the use of setting up individual configs this way? I just assumed this would limit an integration to only it’s own config file.
secrets.yaml is just a txt file to store your passwords etc so that you could exclude the file from being uploaded to git or shared. There isn’t any security on this file i believe