La pagina man di Ubuntu per apt-key include la seguente nota riguardante apt-key add:

Nota: Invece di utilizzare questo comando, un portachiavi dovrebbe essere inserito direttamente nella directory /etc/apt/trusted.gpg.d/ con un nome descrittivo e "gpg" o "asc" come estensione del file.

Non credo di aver mai visto questo consiglio altrove. La maggior parte dei progetti che ospitano i propri repository afferma di scaricare il proprio file chiave e aggiungerlo con apt-key.

1. Qual è la motivazione dietro questo consiglio?
2. Si tratta di un ismo di Ubuntu o si applica a qualsiasi distribuzione basata su APT?

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

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

Questa è la vulnerabilità. Considera due editori di repository, A e B. Nel mondo di Debian 8 e precedenti, le chiavi di entrambi gli editori andavano nel singolo portachiavi globale sui computer 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 propria chiave A , che APT accetterebbe e installerebbe felicemente. Dopo tutto, la chiave di A è attendibile a livello globale per tutti i repository.

La mitigazione è che gli utenti utilizzino portachiavi separati per singoli editori e facciano riferimento a quei portachiavi con Signed-Byimpostazioni individuali nelle definizioni dei loro repository. In particolare, la chiave dell'editore A viene utilizzata solo nel Signed-Byrepository A e la chiave dell'editore B viene utilizzata solo nel Signed-Byrepository B. In questo modo, se l'editore A soppianta il repository dell'editore B, APT non accetterà i pacchetti sovversivi dal momento che essi e il il repository è firmato dalla chiave dell'editore A non dall'editore B.

Il /etc/apt/trusted.gpg.dmeccanismo a portata di mano è una casa a metà strada in qualche modo difettosa di un povero anziano verso questo, a partire dal 2005 o giù di lì, che non è abbastanza buona. Imposta il keyring 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 di pacchetti gestisce la prevenzione dell'installazione del pacchetto di portachiavi del publisher A, questo è il mio repository, sull'editore B, nel modo normale in cui gestisce i conflitti di file tra i pacchetti in generale.) Ma lo aggiunge ancora all'insieme di chiavi che è considerato globalmente affidabile per tutti i repository. Il meccanismo completo esistente ora utilizza file keyring separati, non globalmente attendibili /usr/share/keyrings/.

Le mie istruzioni sono già lì. ☺ Ci sono passi avanti per spostare i repository di Debian su questo meccanismo, in modo che non utilizzino più nemmeno chiavi affidabili a livello globale. Potresti voler parlare con la "maggior parte dei progetti" che hai trovato. Dopotutto, ti stanno attualmente insegnando a consegnare loro l'accesso globale ad APT sul tuo computer.

Ulteriori letture

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

apt-key delprende il keyid, che è un hash insignificante della chiave.

È più semplice se puoi disinstallare le chiavi usando un nome significativo ... come un nome file.

Come dice JdeBP, funziona perfettamente con i file di chiavi attendibili installati come parte di un pacchetto debian. Penso che possa anche essere più bello quando hai installato manualmente un file chiave.

Nel nuovo meccanismo attualmente in "sperimentazione iniziale", questo è ulteriormente semplificato. Devi solo rimuovere / disabilitare una cosa: il repository (in sources.list / sources.list.d). Ciò smetterà automaticamente di consentire la chiave configurata per quel repository (a meno che non sia stata utilizzata anche da un altro repository).

Non so come sfruttare il nuovo meccanismo per la sicurezza. Suppongo solo che ho bisogno di fidarmi di qualcuno se uso il loro pacchetto. Il processo di installazione del pacchetto è ancora in esecuzione come root:-).