Make a snapshot. Update. If it does, you can simply revert. This should be standard update procedure anyways.
It may not be deliberate by the custom component. Just that input isn’t being sanitised and therefore exploitable.
Good point, thanks. Due to my line of work I typically jump to malicious actors, because I’ve seen it all!
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!
i get that it’s not about HA. but you didn’t say how/what about 2021.1.2 addresses the issue.
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.
“Hass.io” is not a term we use anymore. It was ambiguous by itself as well.
This is a new release of the Home Assistant Core application, which runs on all, no matter which installation method you use.
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.
can use ssh addon.
ha core update --version 2021.1.2
It should be available though… I got a notification a few hours ago
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?
Thank you
Are you saying you think a custom component shouldn’t be able to read configuration.yaml?
If so, how would you configure a custom component?
If you meant something else, my apologies.
Do you think it might be an idea to put the pitchforks down and wait for more information which is surely forthcoming?
Is this why Alexa sensors {timer, alarm, ect} are no longer available?
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.
For organization not security
Files can be separated to make more human readable and allow config separate in manner logical to user.
Nothing to do with security
secrets.yaml was for security. Remove passwords from config. Not sure how access to this is managed for integration
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
Lucky you, it’s cold here (US) in most of the states. Enjoy your weather!