Hinweis:Anstelle dieses Befehls sollte ein Schlüsselbund
direkt im Verzeichnis /etc/apt/trusted.gpg.d/ mit einem
aussagekräftigen Namen und entweder „gpg“ oder „asc“ als Datei abgelegt werden Erweiterung.

Ich glaube, ich habe diesen Rat noch nie woanders gesehen. Die meisten Projekte, die ihre eigenen Repositories hosten, sagen, dass sie ihre Schlüsseldatei herunterladen und mit apt-key hinzufügen sollen .

1. Was ist die Motivation hinter diesem Ratschlag?
2. Ist das ein Ubuntu-Ismus oder gilt es für jede APT-basierte Distribution?

Akzeptierte Antwort:

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. Tatsächlich ist dieser Teil des Handbuchs jetzt veraltet, da es sich um das falsche Verzeichnis handelt.

Das hat nicht wirklich etwas mit .d zu tun Verzeichnisse und mehr, die mit dem Verhindern einer Cross-Site-Schwachstelle in APT zu tun haben. Das ältere System verwendete aus praktischen Gründen separate Schlüsselbunddateien, aber dies ist jetzt aus Sicherheitsgründen erforderlich. dein Sicherheit.

Dies ist die Schwachstelle. Betrachten Sie zwei Repository-Herausgeber, A und B. In der Welt von Debian 8 und früher gingen die Schlüssel beider Herausgeber in den einzigen globalen Schlüsselbund auf den Computern der Benutzer. Wenn Herausgeber A es irgendwie arrangieren könnte, die Repository-WWW-Site von Herausgeber B zu ersetzen, dann könnte A subversive Pakete veröffentlichen, die mit dem eigenen Schlüssel von A signiert sind , die APT gerne akzeptiert und installiert. Dem Schlüssel von A wird schließlich global für alle Repositories vertraut.

Die Abschwächung besteht darin, dass Benutzer separate Schlüsselbunde für einzelne Publisher verwenden , und diese Schlüsselbunde mit individuellem Signed-By zu referenzieren Einstellungen in ihren Repository-Definitionen. Insbesondere wird der Schlüssel von Herausgeber A nur im Signed-By verwendet von Repository A und der Schlüssel von Herausgeber B wird nur im Signed-By verwendet von Repository B. Auf diese Weise, wenn Herausgeber A das Repository von Herausgeber B ersetzt, wird APT die subversiven Pakete von ihm nicht akzeptieren, da sie und das Repository mit dem Schlüssel von Herausgeber A und nicht mit dem von Herausgeber B signiert sind.

Die /etc/apt/trusted.gpg.d Der Mechanismus zur Hand ist ein etwas fehlerhafter Mittelweg eines älteren armen Mannes aus dem Jahr 2005 oder so, der nicht gut genug ist. Es richtet den Schlüsselbund in einer separaten Datei ein, sodass er gepackt und einfach in einem Schritt von einem Paketmanager installiert (oder mit fetch heruntergeladen werden kann /curl /wget ) wie jede andere Datei. (Der Paketmanager sorgt dafür, dass der spezielle dies-ist-mein-Repository-Schlüsselbund von Herausgeber A verhindert wird Paket von der Installation über Herausgeber B, auf die normale Weise, wie es Dateikonflikte zwischen Paketen im Allgemeinen handhabt.) Aber es fügt es dennoch dem Satz von Schlüsseln hinzu, dem global für alle Repositories vertraut wird. Der vollständige Mechanismus, der jetzt existiert, verwendet separate, nicht global vertrauenswürdige Schlüsselbunddateien in /usr/share/keyrings/ .

Meine Anleitung ist schon da. ☺ Es gibt Bestrebungen, Debians eigene Repositories auf diesen Mechanismus umzustellen, sodass sie auch keine global vertrauenswürdigen Schlüssel mehr verwenden. Vielleicht möchten Sie mit den „meisten Projekten“ sprechen, die Sie gefunden haben. Immerhin weisen sie Sie gerade an, ihnen den globalen Zugriff auf APT auf Ihrem Rechner zu übergeben.

Weiterführende Literatur

• Daniel Kahn Gillmor (2017-05-02). Bitte versenden Sie releasespezifische Schlüssel separat außerhalb von /etc/apt/trusted.gpg.d/ . Debian-Fehler #861695.
• Daniel Kahn Gillmor (2017-07-27). debian sources.list Einträge sollten Signiert-von-Optionen haben, die auf bestimmte Schlüssel verweisen . Debian-Fehler #877012.
• „Sources.list-Eintrag“. Anweisungen zum Herstellen einer Verbindung mit einem Drittanbieter-Repository . Debian-Wiki. 2018.
• Warum stellt das Hinzufügen zu sources.list kein Sicherheitsrisiko dar?
• Debian 9, APT und „GPG-Fehler:… InRelease:Die folgenden Signaturen waren ungültig:“