[Beta V6] FTL-Checksum error?

[jsuelwald]

pihole-up generates the following:

[...]
[✓] Checking for user 'pihole'

[i] FTL Checks...

[✓] Detected x86_64 architecture
[i] FTL binary already installed. Confirming Checksum...
[✗] Corruption detected, redownloading binary...
[i] Downloading and Installing FTL...pihole-FTL-amd64: FAILED
sha1sum: WARNING: 1 computed checksum did NOT match
[✗] Downloading and Installing FTL
Error: Download of https://ftl.pi-hole.net/development-v6/pihole-FTL-amd64 failed (checksum error)
[✗] FTL Engine not installed

Unable to complete update, please contact Pi-hole Support

[DL6ER]

Please try again, this can sometime happen on intermittent connection issues

[jsuelwald]

Ok, will do.
(And this fixed it)
But.. what kind of intermittent connection issues should corrupt a file downloaded with https?

[pralor-bot]

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/ftl-update-checksum-mismatch-beta-v6/68777/17

[DL6ER]

You are right, TLS/SSL should provide confidentiality and integrity of the transmission. However, this method is designed to keep fraudulent sites from modifying your transmission, less so to to protect the rats from random spurious but flipping. And TLS only does this when the negotiated cipher suite uses a digest algorithm like to compute a Hash-based Message Authentication Code (HMAC). This negotiation happens between your client (curl) and the server and may have picked something odd.

If not, you are still "protected" by the underlying TCP checksummming but remember that this is a 16 bit ones' complement of the ones' complement sum of all 16-bit words in the header and text and very easily fooled when a bit flipped at the correct position. Even when this seems unlikely at first, think about a very intermittent connection with many many errors. TCP will retry most transmission errors but not those it cannot detect.

Pi-hole itself will still reject this file with the error posted above as a flipped bit will result in a vastly different sha1sum of the entire binary. There is no built-in method to retry downloading automatically as the connection issue typically remains for some time and repeating immediately (or in short succession) often doesn't work, either.