How are certificates distributed to computers before the TLS session begins? How does a user trust an untrusted certificate and it's chain, say from Let's Encrypt?
You only distribute public keys to the end user - and private key signed hashes that can be verified by those public keys.
The user is given an option to trust a key for a new repo, when it's not in their list of trusted keys. The installation already comes with a list of trusted keys when it begins. If you trust it, then you run it - just like you should be trusting the root certificates in your system to really benefit from TLS, even. That includes Government, Telco and Company issued certificates. :-)
> How are certificates distributed to computers before the TLS session begins? How does a user trust an untrusted certificate and it's chain, say from Let's Encrypt?
A handful of root certificates are baked into every OS and carefully guarded at every level to make sure they’re never given to someone who doesn’t have possession of a domain. Are you proposing to do this for GPG checksums? What would that look like?
It's the same logical process. A list of public keys that are trusted for installations are already kept in the OS. When updating, first they download packages are public key updates, and signed with the old key.
The user is also alerted if this key update happened because there may have been a private key compromise, or if this is a cryptographic strength/algorithm update, or a key rotation etc.
Once the user decides to verify the information, do their research - and approve, the new keys are now used to verify signed packages. So on and so forth.
The deal is that you do not rely on TLS to fetch this package update information at all. You merely download the signed hashes required to verify package authenticity and proceed.
Even before the OS exists, it tells you that so-and-so is their public key, download the ISO, verify the signed hashes with their public keys. Once you trust and install with this ISO, the update process can take care of the rest.
You can do that research with other systems. Not the one where you are stuck because of outdated protocols, certificates etc.
Besides, if your system is not following the most secure TLS version or having the most up-to-date certs, what is the point in browsing something with TLS? It should be plaintext compatible.
You only distribute public keys to the end user - and private key signed hashes that can be verified by those public keys.
The user is given an option to trust a key for a new repo, when it's not in their list of trusted keys. The installation already comes with a list of trusted keys when it begins. If you trust it, then you run it - just like you should be trusting the root certificates in your system to really benefit from TLS, even. That includes Government, Telco and Company issued certificates. :-)