Few minutes ago I come to another conclusion.
Besides of technical/technological-wise motivations there is what is happening:
the changes haven’t been discussed with community (I’m not aware of it, but it’s my guess seeing the reaction of the community
the changes have been implemented without information shared prior to this fact, which could make us better prepared for that
devs left us alone with the problem, letting some unauthorized forum users to defend development decisions. It leads to unnecessary flame wars and obviously solves nothing.
If you track posts other than flame ones, you can see that setting more secure passwords don’t always work. And again: no support from devs. Community members try to help, but at some point they cannot help anymore.
In other words, putting motivations aside, the whole transition is not executed properly. Maybe improvement in transparency and execution areas could help more, even in case that we cannot agree with particular feature. But at least it would not compromise reliability of our systems.
I get that it’s their project and we are merely consumers of it, but something like this should have had an prior announcement or even some sort of beta testing. A pull from less than 2 weeks ago seems awfully rushed to me.
I have done both of those - the api is blocked and the attempts show in the firewall logs as blocked. The system logs confirm this.
I have also made the changes to the config.yaml file, too and the alerts STILL continue.
I have now added an automation to remove the alerts but this is, frankly, ludicrous when all that is needed is a button with a few warnings about taking your life into your own hands if you disable the alerts!
However complex the process of disabling this check (NOTE: it is the check that I want to stop, not only the alert) actually is, is it too much to ask for it to be documented - and the change communicated - in advance of springing this on the community?
It happens on a surprisingly fairly regular basis.
The devs make a decision, tell nobody, people notice because it starts impacting them, there’s a big uproar, they and others start circling the wagons (“stop complaining”, “it’s free so you get what you pay for”, “if you don’t like it submit a PR” (that gets tossed immediately…), “what have YOU done to support HA lately?”, etc, etc).
Most of the time the issue gets ignored and people end up just having to live with it and/or do workarounds to get the exact same functionality back as there was before. So it completely thwarts any “benefit” that they think the change bestowed so all it did was cause a bunch of drama for nothing.
Occasionally (a la Supervised installs) the devs figure out people aren’t happy, undo the change and vow to do better next time communicating changes to the users. Until there is a next time and the cycle continues…
Earlier I mentioned blocking api.pwnedpasswords.com but I’ve now switched to another method. Instead of blocking access I modified the code so it suppresses the request to api.pwnedpasswords.com.
I changed the line to:
_API_CALL = "https://127.0.0.1/range/{hash}"
Restart Supervisor and it no longer makes the request to the external URL. This method provides the following benefits:
No log message in PiHole indicating the request was blocked.
No log message in Supervisor indicating it couldn’t access the URL.
The drawback is that code modifications are undone the moment Supervisor is upgraded. To make things easier, I’ve created a shell script to perform the code modification. FWIW, the same script is also used to ‘patch’ some other code as well (throttle the frequent requests to version.home-assistant.io).
I blocked it at my firewall as I know that other things like password managers (1password, in particular) are using this same method. Since I really don’t want to use HIBP in any way, shape or form outside of my own checking, I decided to just block it at the firewall level and be done with it.
I don’t want hassio send my passwords, my password hashes or part of them to anybody!
If someone will expoit pwnedpasswords.com they will know that at my IP address has wake password associated. Not so cyber safe!
Please make this feature configurable!
Hi guys, I’m finally back from the land of limited internet and knocked this addon up last night.
It’s very much an at your own risk solution but it’s working for me. Hopefully the devs will give us the opt out option, or at the very least not intentionally break the addon.
Thanks for showing this method. I think this will work to solve another problem of mine, namely that self-signed certs must be re-added every supervisor upgrade. This style of add-on can resolve that as well…
It boggles my mind that the world has come to this: adding a complete virtual OS to do something as simple as slightly modify a file or two…
To anyone interested, the password check can now be disabled with the command below in the CLI using the latest versions of either the core-ssh add-on or the community ssh add-on:
Terminal & SSH (core) version 9.1.0
SSH & Web Terminal (community) version 8.0.4
ha resolution check options --enabled=false addon_pwned
You are right. It doesn’t work anymore.
Cannot verify if only command doesn’t work or the feature itself has been removed (if Superviser stick with enabed=false addon_pwned)