| [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. |