TLS uses message authentication codes which should detect tampering or bit errors. In theory, a cosmic ray could hit the RAM of the device on the receiving end and bit flip after the ISO has been decrypted but still in RAM. Checksumming does not rule bit flips out though as you could checksum the ISO and the bitflip happens between then and when the ISO is actually used to install the system.
Maybe in theory you could checksum the post installed filesystem, but Im not sure if any distros actually do that or not and it would require deterministic install layouts.
It can fail mid-way of course, but it really shouldn't corrupt in any other way. HTTPS is authenticated after all and malicious manipulation is harder to defend against than accidental corruption. But this is reality and you can have bugs and errors outside the transport of course. Your file system could corrupt data, your drive could be bad etc.
For security you want signatures with a known, trusted key.
TLS uses message authentication codes which should detect tampering or bit errors. In theory, a cosmic ray could hit the RAM of the device on the receiving end and bit flip after the ISO has been decrypted but still in RAM. Checksumming does not rule bit flips out though as you could checksum the ISO and the bitflip happens between then and when the ISO is actually used to install the system.
Maybe in theory you could checksum the post installed filesystem, but Im not sure if any distros actually do that or not and it would require deterministic install layouts.
It can fail mid-way of course, but it really shouldn't corrupt in any other way. HTTPS is authenticated after all and malicious manipulation is harder to defend against than accidental corruption. But this is reality and you can have bugs and errors outside the transport of course. Your file system could corrupt data, your drive could be bad etc.
For security you want signatures with a known, trusted key.