Die Ubuntu-Manpage für apt-key enthält den folgenden Hinweis zu apt-key add:

Hinweis: Anstatt diesen Befehl zu verwenden, sollte ein Schlüsselring direkt im Verzeichnis /etc/apt/trusted.gpg.d/ mit einem beschreibenden Namen und entweder "gpg" oder "asc" als Dateierweiterung abgelegt werden.

Ich glaube nicht, dass ich diesen Rat jemals irgendwo anders gesehen habe. Die meisten Projekte, die ihre eigenen Repositorys hosten, geben an, ihre Schlüsseldatei herunterzuladen und mit hinzuzufügen apt-key.

1. Was ist die Motivation hinter diesem Rat?
2. Ist dies ein Ubuntu-Ismus oder gilt er für eine APT-basierte Distribution?

Diese Projekte haben veraltete Anweisungen. Ich weiß das, weil ich ein Debian-Repository veröffentliche und meine Anweisungen aktualisiert habe, als ich von den Änderungen in Debian 9 APT erfahren habe . In der Tat ist dieser Teil des Handbuchs jetzt veraltet, da es sich um das falsche Verzeichnis handelt.

Dies hat nicht wirklich mit .dVerzeichnissen zu tun, sondern vielmehr mit der Verhinderung einer standortübergreifenden Sicherheitsanfälligkeit in APT. Das ältere System verwendete der Einfachheit halber separate Schlüsselbunddateien, dies ist jedoch jetzt eine Notwendigkeit für die Sicherheit. Ihre Sicherheit.

Dies ist die Sicherheitslücke. Betrachten Sie zwei Repository-Herausgeber, A und B. In der Welt von Debian 8 und früher wurden die Schlüssel beider Herausgeber in den einzigen globalen Schlüsselring auf den Computern der Benutzer eingefügt. Wenn Publisher A irgendwie veranlassen könnte, die Repository-WWW-Site von Publisher B zu ersetzen, könnte A subversive Pakete veröffentlichen, die mit dem eigenen Schlüssel von A signiert sind und die APT gerne akzeptieren und installieren würde. Der Schlüssel von A ist schließlich global für alle Repositorys vertrauenswürdig.

Die Minderung besteht darin, dass Benutzer separate Schlüsselringe für einzelne Herausgeber verwenden und diese Schlüsselringe mit individuellen Signed-ByEinstellungen in ihren Repository-Definitionen referenzieren . Insbesondere wird der Schlüssel von Publisher A nur im Signed-ByRepository A und der Schlüssel von Publisher B nur im Signed-ByRepository B verwendet. Wenn Publisher A das Repository von Publisher B ersetzt, akzeptiert APT auf diese Weise die subversiven Pakete nicht, da sie und das Das Repository wird vom Schlüssel des Herausgebers A und nicht vom Schlüssel des Herausgebers B signiert.

Bei dem /etc/apt/trusted.gpg.dvorliegenden Mechanismus handelt es sich um ein etwas fehlerhaftes Haus eines älteren armen Mannes, das seit etwa 2005 nicht mehr gut genug ist. Der Schlüsselring wird in einer separaten Datei eingerichtet, sodass er von einem Paketmanager (und mit fetch/ curl/ wget) wie jeder anderen Datei in einem Schritt gepackt und installiert werden kann. (Der Paketmanager verhindert, dass das spezielle this-is-my-repository-Schlüsselringpaket von Publisher A über Publisher B installiert wird, wie es normalerweise bei Dateikonflikten zwischen Paketen im Allgemeinen der Fall ist.) Er fügt es jedoch weiterhin dem Schlüsselsatz hinzu Das ist global vertrauenswürdig für alle Repositorys. Der vollständige Mechanismus, der jetzt vorhanden ist, verwendet separate, nicht global vertrauenswürdige Schlüsselringdateien /usr/share/keyrings/.

Meine Anweisungen sind bereits da. ☺ Es sind Schritte im Gange, um Debians eigene Repositorys auf diesen Mechanismus zu verschieben, sodass sie auch keine global vertrauenswürdigen Schlüssel mehr verwenden. Vielleicht möchten Sie sich mit den "meisten Projekten" unterhalten, die Sie gefunden haben. Schließlich weisen sie Sie derzeit an, ihnen den globalen Zugriff auf APT auf Ihrem Computer zu übergeben.

Weiterführende Literatur

• Daniel Kahn Gillmor (2017-05-02). Bitte versenden Sie release-spezifische Schlüssel separat außerhalb von/etc/apt/trusted.gpg.d/ . Debian-Fehler # 861695.
• Daniel Kahn Gillmor (27.07.2017). Debian- sources.listEinträge sollten Signed-by-Optionen haben, die auf bestimmte Schlüssel verweisen . Debian-Fehler # 877012.
• "Sources.list entry" . Anweisungen zum Herstellen einer Verbindung zu einem Repository eines Drittanbieters . Debian Wiki. 2018.
• Warum ist es kein Sicherheitsrisiko, der Datei sources.list hinzuzufügen?
• Debian 9, APT und "GPG-Fehler: ... InRelease: Die folgenden Signaturen waren ungültig:"

apt-key delnimmt das keyid, was ein bedeutungsloser Hash des Schlüssels ist.

Es ist einfacher, wenn Sie Schlüssel mit einem aussagekräftigen Namen deinstallieren können ... wie einem Dateinamen.

Wie JdeBP sagt, funktioniert dies gut mit vertrauenswürdigen Schlüsseldateien, die als Teil eines Debian-Pakets installiert werden. Ich denke, es kann auch schöner sein, wenn Sie eine Schlüsseldatei manuell installiert haben.

In dem neuen Mechanismus, der sich derzeit in "Ersttests" befindet, wird dies weiter vereinfacht. Sie müssen nur eines entfernen / deaktivieren: das Repository (in sources.list / sources.list.d). Dadurch wird der für dieses Repo konfigurierte Schlüssel automatisch nicht mehr zugelassen (es sei denn, er wurde auch von einem anderen Repo verwendet).

Ich weiß nicht, wie ich den neuen Sicherheitsmechanismus nutzen soll. Ich gehe einfach davon aus, dass ich jemandem vertrauen muss, wenn ich sein Paket verwende. Der Paketinstallationsprozess läuft noch wie folgt root:-).