HTTPS e una VPN non autenticano il pacchetto che installi

Un aggiornamento fallisce, e il suggerimento nel thread segue una linea nota: il traffico passa da una VPN, quindi il download deve essere affidabile, e il controllo della firma viene allentato per superare l’errore. Due idee distinte sono state fuse in una sola frase. La cifratura protegge un percorso tra estremi; l’autenticazione decide se i byte provengono dall’editore che intendevi. Un tunnel fornisce la prima e non dice nulla sulla seconda.

Il sintomo è di solito un errore di verifica su un host, in un repository, mentre tutto il resto si aggiorna normalmente. Quella forma dice già che il percorso di rete funziona e che il disaccordo riguarda la fiducia.

Due controlli che rispondono a domande diverse

La sicurezza del trasporto risponde a chi c’è dall’altra parte di questa connessione e se qualcuno sul percorso può leggerla o modificarla. L’autenticazione del pacchetto risponde se questo artefatto è stato pubblicato dall’autorità che hai configurato, e deve sopravvivere a un download attraverso uno specchio che non controlli.

Queste domande si sovrappongono solo ai bordi. Un certificato corretto su uno specchio dimostra che lo specchio è lo specchio; non dimostra che lo specchio contenga contenuto dell’editore non modificato. Un pacchetto firmato dimostra che l’editore l’ha firmato; non ti dice che la rete ha consegnato la versione più recente né che il repository che hai indicato sia quello approvato dalla tua organizzazione.

La modalità di guasto che le persone creano disattivando i controlli è una perdita permanente della seconda garanzia, in cambio di un download riuscito. Quello scambio è invisibile fino al giorno in cui conta.

Che cosa autentica davvero apt

Il modello di APT è una catena di archivio autenticata. I metadati di rilascio firmati portano tramite checksum agli indici dei pacchetti, e quegli indici portano tramite checksum ai singoli file di pacchetto. È la verifica della catena che rende uno specchio non affidabile ma utilizzabile: lo specchio può servire ciò che vuole, e la firma dei metadati decide se APT lo accetta.

Questo deliberatamente non è lo stesso che controllare la firma di un manutentore su ogni pacchetto installato, e la distinzione spiega perché «il pacchetto è firmato» e «l’archivio è autenticato» vengano usati indifferentemente nelle segnalazioni di bug quando significano cose diverse.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

Leggi l’output dell’aggiornamento, non solo il codice di uscita. APT nomina il repository i cui metadati sono falliti, e quel nome è il confine da indagare. Un repository marcato come attendibile senza verifica della firma, o un override per un repository non sicuro, è una decisione di configurazione che qualcuno ha preso e dovrebbe poter spiegare.

La freschezza è di nuovo una proprietà separata. Un file di metadati firmato validamente può essere più vecchio di quello che hai visto la settimana scorsa, per questo i metadati di rilascio portano una scadenza e per questo un problema di orologio sul client può produrre errori di verifica che sembrano problemi di chiave.

Che cosa controlla separatamente dnf5

Il lato RPM espone due interruttori distinti, e confonderli produce la stessa classe di errore nella direzione opposta. Uno controlla se i file di pacchetto devono portare una firma valida; l’altro controlla se i metadati del repository devono essere firmati. Si possono impostare in modo indipendente, e un sistema può essere rigoroso su uno e permissivo sull’altro.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

L’interrogazione del pacchetto mostra come sono i metadati di firma della copia installata, il che è un utile controllo di realtà rispetto a un file di configurazione che dichiara rigore. Ciò che non ti dice è la politica supportata della distribuzione, ed è quella che dovresti seguire invece di un’istruzione generica «attiva GPG» da un forum.

Dove i due gestori differiscono, la differenza è architetturale e non un segno che uno sia più debole. Entrambi autenticano il contenuto dell’editore; collocano la firma in punti diversi della catena.

Che cosa aggiunge il tunnel e che cosa no

Una VPN può fornire una rotta necessaria, tenere il traffico di aggiornamento fuori da una rete di accesso non affidabile e ridurre ciò che vede un osservatore locale. Sono vantaggi operativi reali, e nessuno di essi è autenticazione dell’editore.

HTTPS aggiunge la propria garanzia, ed è più stretta di quanto sembri. Autentica l’estremo TLS a cui ti sei connesso. Se quell’estremo è uno specchio, hai autenticato lo specchio, non il contenuto dell’archivio che serve. Questo è esattamente il caso per cui esiste la catena di metadati firmati.

Nessuno dei due controlli promette disponibilità. Una rete può negare la consegna, e un oggetto autenticato non è automaticamente il più recente. Usa la politica di freschezza del gestore di pacchetti stesso invece di dedurla dalla presenza di un’icona a forma di lucchetto.

Diagnostica il confine che ha fallito

Nomina la fase prima di cambiare qualsiasi cosa: risoluzione DNS, il proxy o la rotta, l’identità dell’estremo TLS, l’autenticazione dell’archivio, i controlli di firma del pacchetto o l’installazione. Ognuna ha una forma di errore e un proprietario distinti.

Riparare un percorso di rete non dovrebbe mai comportare dichiarare attendibile una chiave di firma sconosciuta, ignorare certificati o accettare una configurazione di repository che non hai chiesto. Se una chiave è stata davvero ruotata, la distribuzione o il proprietario del repository pubblicano la nuova chiave attraverso un canale che puoi verificare, e questa è la correzione da applicare.

Annota quale confine ha fallito e chi ne è responsabile. Il prossimo errore di aggiornamento sarà a un confine diverso, e avere l’elenco lo rende una diagnosi di cinque minuti invece di un’altra discussione sul fatto che il tunnel renda sicuri gli aggiornamenti.