On Mon, Dec 10, 2018 at 07:44:13PM +0100, Alberto Cammozzo wrote:
So come funziona, ma se devi scaricare il cksum dallo stesso repository e questo è compromesso oltre al binario anche il cksum sarà manomesso (e corretto).
Il checksum manomesso sarà corretto. Ma la *signature* sul checksum non potrà esserlo, perché solo il maintainer/autore del software la può produrre con la sua chiave privata. L'hoster del repository malfido non può produrla perché non ha la chiave. Quindi continuo a non vedere il tipo di attacco che stai cercando di evitare. L'unico "attacco" possibile è che l'hoster *tolga* la signature del maintainer, ma è un attacco con le virgolette del caso perché se il client (il package manager) è fatto bene rifiuterà di installare un pacchetto il cui checksum non è firmato. E quindi gli utenti smetteranno di usare il repository perché semplicemente, dal loro punto di vista, non funziona.
In un repository trusted mi aspetto che chi lo gestisce controlli che i cksum non siano stati alterati -- suppongo Debian lo faccia, e suppongo anche che apt-get non si fidi di http per scaricare i checksum.
apt-get scarica i checksum via http (e persino ftp...) senza problemi, e pure da mirror terze parti, proprio per il motivo di cui sopra: sebbene i checksum possono essere manomessi da terze parti, le signature non possono esserlo. Tornando alla blockchain, puoi certamente immaginare di distribuire le signature via essa ed avere dei client che le cercano nella blockchain anziché nel repository stesso. Ma a quel punto stai usando una blockchain semplicemente come se fosse una CDN per dei file particolari. Funziona, ma non c'è nessun valore aggiunto dato dall'uso della blockchain. Ed il motivo è che i meccanismi di integrità del software basati su signature sono verticali (maintainer / autore / distributore) e non orizzontali, quindi il consenso distribuito non aggiunge nulla. A presto -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »