Content Trust with Home Assistant & Codenotary CAS

We started to update how Home Assistant does content trust using Codenotary CAS.

With content trust, we can ensure that your system only runs containers/software as released by the original author. The author, in this case, can be the Home Assistant project, but also, for example, an add-on developer. This is an important security aspect, as it protects your instance from running possibly malicious software. Content trust verifies that the software you download, install or upgrade is exactly the same as it was released by its creator and ensures nobody messed with it along the way.

Codenotary CAS is built around a decentralized, cryptographically coherent and verifiable database technology called immudb. It is used to store all these trusted content signatures.

With immudb we will be able to host parts of the trusted content signatures data ourselves (we don’t do this yet). It could even be made available as a Home Assistant add-on that users can install locally. Important to know is that CAS does not upload any user data for verification, it’s all done locally, just the way we like it. When you install or update part of your system that is signed, it checks the CAS database to ensure that the image has not been revoked (similar to SSL with the CRL) and verifies that the download content, which we deliver over multiple public endpoints, is the same as the update that your system just has downloaded.

While rolling out the new system we ran into some issues which caused users unable to install updates for ~12 hours on March 11; for which we want to apologize. Thanks to the help from Codenotary engineers we were able to get it fixed in a quick and orderly fashion.


This is a companion discussion topic for the original entry at

What versions of Home Assistant does this impact?

Do all add-on authors have to implement code-signing ?

I just hope this won’t cause a hoops of issues if we, e.g. want to build our own image above the official one…

What happens if / when “codenotary” finds discrepancies? When is this executed?
This pilling up of dependencies / locking / controls mechanisms gets on my nerves…


It is not impacted by the Home Assistant Core version, as this is a feature provided by the Supervisor.

No, it is optional. Add-on authors can choose to sign their releases and add extra security. Those add-ons will get a visible badge showing it is a signed add-on. If they don’t, nothing changes.

Not more than usual. Please note, this is an iteration of the existing content trust implementation we had already; it is not a new thing or new concept for Home Assistant. We did update to use CAS (instead of the previous VCN) and made it available for add-ons now as well.

If an add-on explicitly enabled signing, but the download release doesn’t match the signature, it will refuse to install the update and it will log the error/issues.

These aren’t locking or control mechanisms, but a security protection/enhancement measurement.

Code/package/container signing is a very normal and common practice, done by virtually all systems out there. Including (but not limited to) Windows app (developer certificates), Mac app (also certificates), Linux packages (GPG signing of for example apt packages), Docker containers (DCT, Codenotary, Sigstore cosign). It is really not that odd.

If you like to force/override to install something without a signature or even if a signature is invalid that is possible, but not recommended.


Thank you for the explanation frenck. That is useful. I see you have updated a couple of your addons to use it.

1 Like