So we have had a few updates of the Core since this disaster hit… HasS it become configurable yet?
Ironic that all of the documentation of the system updates is silent to this “feature”
So we have had a few updates of the Core since this disaster hit… HasS it become configurable yet?
Ironic that all of the documentation of the system updates is silent to this “feature”
It’s not ironic. It’s scary.
No discussion prior to implementation, accepted merge request withou objections, no info in blog post, no mention in docs.
Isn’t it too many coincidences?
Now I expect a response (I got in the past): “as HA user you are obligued to track merge requests on your own.”
It was in the supervisor release notes
Then it’s even “better” since supervisor is updating on its own.
I forgot to add to the list: no comment on this feature from developers after its premiere
Ironic that I can’t find ANY HAAS Supervisor release notes on the Home Assistant website. And on the GitHub site the release notes are cryptic and are buried links within links.
And as others posted, even more ironic that the Supervisor “auto updates” something that I didn’t know till just now.
This was not managed well by the great team behind HASS and HASSio.
I don’t think it’s ideal that it’s auto updated. Maybe an option to opt out of that
Ya after a bit of googling I found that there, it is no where on the HASS web page… one tiny burried reference on GitHub. While I applaud the fact that the HAAS change control process is public. You have to admit that was a thin chain and review of a controversial change.
If you follow the review and test chain, it is clear that at least one “Admin” recognized that this was likely going to generate questions and questioned if they needed a review/change of HASS privacy policies. And that question/concern was answered by referencing the blog of the very company that they were planning to use! No conflict of interest there!
To add to that, the ‘proposed change’ section of the templated text for explaining what the pull request is for is blank, so the only clue as to what is going on for those that don’t understand the code is the cryptic title - I’ve never heard of ‘resolution centre’ in homeassistant before reading that PR title and have absolutely no idea what it is. Would never have been able to work out what this PR was for to have been able to add a suggestion like “this should be optional” to it before it was merged. Still worries me a bit that nobody on the dev team thought it should be optional before approving the changes tbh, but I’d forgive that oversight if there was the slightest acknowledgement that they made a mistake.
This came up in another thread. Does anyone know if it sustains a reboot?
I assume it would but why not just test it?
I would expect it will not be exposed in the GUI right now. It seems to be a new command (there was an update to the SSH community addon today. I would not expect it to disable anything else
You’re probably right. Have not had the opportunity yet.
I actually posted it wrong. The check you want to disable is addon_pwned
. I corrected that above and at the other threads.
@maxym I locked those so that the command would remain front and center. Or rather, at the end of the thread and not scroll away. Yes, it’s new.
If you set core_security
to false you should set it back to true.
I see this marked as a solution in three different threads. It mentions HA Core and SSH.
Does this block the supervisor from checking SAMBA passwords?
So let me get that right. The official ‘solution’ to this issue is an obscure command line switch rather than a simple consent dialog with an opt in/out checkbox ? Did I understand this right ?
To be fair, UI elements are almost always harder to implement over CLI commands and usually take a couple of releases to get implemented. Personally, I’m glad that a CLI command got implemented quickly over having to wait for a UI solution.
It’s a change to the supervisor. All supervisor settings are done through SSH, this is no exception. That doesn’t mean that supervisor settings will be exposed to the UI in the future. However the UI currently does easily support a UI configuration. So what would you rather have? A UI setting a year from now with the ability to turn this off, or a command that can be performed now and possibly a UI setting a year from now?
It’s a dialog box. I don’t know much about how they build the UI framework for HA, but normally that’s one or two lines of code.
Anyway. As long as this is eventually pushed to the UI, good. Because the command line would be nothing more than a short term band aid.
LOL yeah, I used to say that too until I really started digging into the Lovelace UI code. Trust me on this, it’s not nearly as simple as one or two lines of code.
If adding a simple dialog box is such a humongous task that would take a year to implement, and I have a hard time believing this but I’ll take your word for it, then this password checking feature needs to be disabled until such a consent UI is possible.