Scopo del controllo dell'integrità negli installatori

L'estrazione di dati compressi non "inevitabilmente" fallirà. Gli errori saranno spesso rilevati, e questo perché la maggior parte dei formati di compressione include già i checksum. La maggior parte, ma non tutti. Ad esempio, l'algoritmo di compressione DEFLATE , di per sé, non include alcun checksum. I checksum vengono aggiunti in alcuni strati esterni, ad es. quando DEFLATE viene utilizzato per un file GZIP (viene quindi utilizzato CRC32). Un installatore può decidere di confezionare tutto con un unico controllo di integrità generale per l'intero archivio, evitando così tali checksum sui singoli elementi.

Se preferisci, ogni volta che un formato di compressione include un checksum, il checksum è effettivamente una "funzione di integrità". Poiché una RAM cattiva può capovolgersi un po 'nella posizione sbagliata, una sorta di checksum è una precauzione ragionevole quando si distribuisce il software (conoscevo un router CISCO che alterava i bit nei pacchetti IP per una tale ragione: i checksum TCP non sempre colgono il problema, quindi qualsiasi file più lungo di 12 megabyte rischiava di essere danneggiato durante il trasferimento attraverso quel router).

I checksum non possono proteggere da alterazioni dannose, perché chiunque esegua la modifica può anche ricalcolare i valori di checksum corrispondenti. Se vuoi un controllo di integrità che funzioni contro attaccanti , allora hai bisogno dei cannoni pesanti, cioè firme digitali .

Mi è capitato più di una volta che un download fosse interrotto e quindi incompleto, ma il controllo dell'integrità continuava a funzionare. Sembra che il controllo dell'integrità sia fatto prima di disimballare.

Come misura di sicurezza, non vedo come sarebbe di alcun valore dal momento che un utente malintenzionato quasi sicuramente sovrascrive l'intero programma e non solo una piccola parte di esso.