UPDATE
Sadly, my simple modification of Supervisor’s source-code is no longer permitted.
The following PR 2789 was implemented in supervisor-2021.04.3
and now checks Supervisor’s source-code for modifications. If it encounters any, it marks the instance as being unsupported and unhealthy.
Although the PR claims the following:
People can run what ever they want, it should just not show as supported.
It didn’t meet its stated goal; you can’t run whatever you want. Now that the system is deemed to be unhealthy it prevents you from installing additional Add-ons.
In addition, of the two systems I have (both running Home Assistant Supervised on Debian) the one on an RPI3 prevented me from opening the existing, installed Add-ons. I’m not sure why it behaved differently from the other (which is installed on a generic Intel-based machine) but it certainly got my attention because that’s how I discovered it was unhealthy due to ‘source_mods’.
I suspect the PR was introduced to protect users from malicious changes to Supervisor. However, anyone able to make such changes can also disable the new self-checking function (thereby rendering the PR moot).
I don’t want to disable the self-check function in order to throttle connectivity/version checks, so I’ve asked the development team to consider making the intervals user-definable. For example, the mods I made (consisting of simply altering two integer values) reduce the connectivity check to every few hours and the version check to once a day.
On a separate note, if you were the victim of malicious changes to Supervisor, there’s no ha supervisor
command to replace the existing Supervisor docker image with a fresh copy (update
won’t work if you’re already running the latest version, neither will repair
). I imagine you’ll have to use docker pull
assuming you know something about docker while you’re freaking out that you somehow managed to install a hacked copy of Supervisor.