Stai affermando con forza che aggiungere HTTPS ai mirror PPA sopra il meccanismo di firma del codice è un miglioramento della sicurezza. Diamo un'occhiata a ciò che stanno facendo queste due cose:
Firma codice
Non ho familiarità con il modo in cui la firma del codice funziona in Ubuntu / apt e non ho avuto successo nel trovarlo su Google. I pacchetti sono firmati dagli sviluppatori o dallo stesso mirror? Se qualcuno ha un link, sarei grato. Presumo che siano firmati dallo specchio perché ciò ha più senso.
Quindi, il modello di sicurezza è che hai un file .deb che vuoi installare (il metodo con cui l'hai ottenuto è irrilevante), e puoi verificare la firma sul pacchetto per assicurarti che sia autentico. A meno di un aggressore che ruba la chiave privata e firma la propria versione, questo sembra abbastanza a tenuta d'acqua.
HTTPS / TLS
Il valore aggiunto è che il server può dimostrare crittograficamente che è chi dice di essere e tutte le comunicazioni non possono essere Man-in-the-Middle'd. Diamo un'occhiata in dettaglio:
Caso 1: Né la chiave di firma del codice PPA o la chiave del server HTTPS sono compromesse
Tutto è buono. Hai una doppia protezione. HTTPS non aggiunge alcun valore.
Caso 2: chiave di firma codice PPA non compromessa, chiave server HTTPS compromessa
Questo è equivalente alla pratica corrente di non avere HTTPS. Quindi un utente malintenzionato può MitM la tua connessione a https://ppa.launchpad.net e quindi apt non sarà in grado di fornirti una versione dannosa del file .deb . MA non sarai in grado di installarlo perché la firma non verrà verificata correttamente. HTTPS non aggiunge alcun valore.
Caso 3: chiave di firma codice PPA compromessa, chiave del server HTTPS non compromessa
L'attaccante non sarà in grado di MitM la tua connessione a https://ppa.launchpad.net . HTTPS è valore aggiunto.
Caso 4: entrambi i tasti sono compromessi
Sei nei guai. HTTPS non aggiunge alcun valore.
L'unico caso in cui HTTPS aggiunge valore è se la chiave di firma PPA è compromessa, ma la chiave TLS del server non lo è. Quanto è probabile che ciò accada? Chiaramente i responsabili del design di questo sistema non considerano una minaccia significativa. Come @kay ha detto in questa risposta, se vuoi mettere sotto pressione questo problema, allora inserisci un bug.
Per inciso, lo schema di progettazione dell'utilizzo di HTTP per i protocolli dotati di crittografia incorporata è abbastanza comune e accettato. Si tratta di una progettazione di protocollo molto simile a, ad esempio, CMP o AIA per la gestione dei certificati: non è necessario che questi protocolli superino TLS poiché il protocollo stesso ha una protezione crittografica incorporata. Inoltre, l'entità di origine che si desidera autenticare è la CA (o in questo caso, il firmatario del codice), di cui è irrilevante il particolare mirror del file. (confronta questo con il caso d'uso per cui TLS è progettato, per esempio, connettendosi a www.facebook.com dove l'identità del server è la parte importante).