Nota:invece di utilizzare questo comando, è necessario inserire un portachiavi
direttamente nella directory /etc/apt/trusted.gpg.d/ con un nome descrittivo
e "gpg" o "asc" come file estensione.

Non credo di aver mai visto questo consiglio da nessun'altra parte. La maggior parte dei progetti che ospitano i propri repository dice di scaricare il file della chiave e aggiungerlo con apt-key .

1. Qual ​​è la motivazione alla base di questo consiglio?
2. Si tratta di un Ubuntu-ism o si applica a qualsiasi distribuzione basata su APT?

Risposta accettata:

Quei progetti hanno istruzioni obsolete. Lo so perché pubblico un repository Debian e ho aggiornato le mie istruzioni quando ho scoperto le modifiche in Debian 9 APT. In effetti, questa parte del manuale non è aggiornata, poiché è la directory sbagliata.

Questo non ha davvero a che fare con .d directory e altro a che fare con la prevenzione di una vulnerabilità tra i siti in APT. Il vecchio sistema utilizzava file di portachiavi separati per comodità, ma ora questa è una necessità per la sicurezza; tuo sicurezza.

Questa è la vulnerabilità. Prendi in considerazione due editori di repository, A e B. Nel mondo di Debian 8 e precedenti, le chiavi di entrambi gli editori sono state inserite nel singolo keyring globale sulle macchine degli utenti. Se l'editore A potesse in qualche modo provvedere a soppiantare il sito WWW del repository dell'editore B, allora A potrebbe pubblicare pacchetti sovversivi, firmati con la chiave di A , che APT accetterebbe e installerebbe volentieri. Dopotutto, la chiave di A è affidabile a livello globale per tutti i repository.

La mitigazione è che gli utenti possano utilizzare keyring separati per i singoli publisher e per fare riferimento a quei portachiavi con Signed-By individuali impostazioni nelle loro definizioni di repository. In particolare, la chiave dell'editore A viene utilizzata solo nel Signed-By del repository A e la chiave dell'editore B viene utilizzata solo nel Signed-By del repository B. In questo modo, se l'editore A soppianta il repository dell'editore B, APT non accetterà i pacchetti sovversivi da esso poiché essi e il repository sono firmati dalla chiave dell'editore A e non da quella dell'editore B.

Il /etc/apt/trusted.gpg.d il meccanismo a portata di mano è la via di mezzo un po' imperfetta di un vecchio povero verso questo, dal 2005 o giù di lì, che non è abbastanza buono. Imposta il portachiavi in ​​un file separato, in modo che possa essere impacchettato e installato in un solo passaggio da un gestore di pacchetti (o scaricato con fetch /curl /wget ) come qualsiasi altro file. (Il gestore dei pacchetti si occupa della prevenzione dello speciale this-is-my-repository-keyring dell'editore A pacchetto dall'installazione su editore B, nel modo normale in cui gestisce i conflitti di file tra i pacchetti in generale.) Ma lo aggiunge comunque al set di chiavi che è globalmente attendibile per tutti i repository. Il meccanismo completo che esiste ora utilizza separato, non file di portachiavi affidabili a livello globale in /usr/share/keyrings/ .

Le mie istruzioni sono già lì. ☺ Sono in corso delle mosse per spostare i repository di Debian su questo meccanismo, in modo che non utilizzino più chiavi affidabili a livello globale. Potresti voler scambiare una parola con la "maggior parte dei progetti" che hai trovato. Dopotutto, ti stanno attualmente chiedendo di consegnare loro l'accesso globale ad APT sulla tua macchina.

Ulteriori letture

• Daniel Kahn Gillmor (02-05-2017). Spedisci le chiavi specifiche per la versione separatamente al di fuori di /etc/apt/trusted.gpg.d/ . Bug Debian #861695.
• Daniel Kahn Gillmor (27-07-2017). debian sources.list le voci dovrebbero avere opzioni di firma che puntano a chiavi specifiche . Bug Debian #877012.
• "Voce Sources.list". Istruzioni per la connessione a un repository di terze parti . Wiki Debian. 2018.
• Perché non è un rischio per la sicurezza aggiungere a sources.list?
• Debian 9, APT e "Errore GPG:… InRelease:le seguenti firme non erano valide:"