Comment by Terr_

[Followup] To over-communicate in the hope that it somehow resolves things, we already have this chain of trust:

1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant.

2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a user who can do that doesn't need to.

3. The daemon is already coded to trust a replacement/successor installer if it meets certain criteria, which are:

3a. It comes from a trusted domain name it already knows should be owned by the same developer/company.

3b. The remote end is authenticated to "be" that domain via certificates from the (trusted) OS.

3c. The content is protected from tampering due, becauese we trust that TLS/SSL encrypts it.

That all already exists, it does not need to be torn down or rebooted. The proposal here is to simply to harden it with a new requirement in the next version:

3d. The next install must be signed by a trusted key-pair that was shipped with the current install.

This improves trust because it means an attacker would also need to compromise keys held in a release pipeline, which is much easier to secure than a CDN/webserver.