Einen VPN-Client herunterzuladen ist eine einmalige Entscheidung; das Hinzufügen seines APT-Repositoriums nicht. Letzteres teilt dem Paketmanager mit, woher künftige Software kommen darf, und das ist eine dauerhafte Übertragung von Autorität statt eines Downloads. Das kann die richtige Regelung sein, wenn der Anbieter ein Repositorium ordentlich pflegt. Es verdient dennoch eine bewusste Entscheidung, und die meisten Installationsanleitungen überspringen sie.

Eine Signatur beglaubigt ein Archiv, nicht dessen Code

APT prüft signierte Repositorium-Metadaten und vertraut dann den Prüfsummen in diesen Metadaten für die Pakete, die es holt. Das beweist, dass das Archiv dem entspricht, was der Schlüsselinhaber veröffentlicht hat, und nichts über den Code darin. Ein korrekt signiertes Paket kann weiterhin unsichere Maintainer-Skripte enthalten, und diese Skripte laufen als root, während das Paket installiert wird. Das apt-secure-Handbuch zieht genau diese Grenze zwischen Archivbeglaubigung und einer Prüfung der Software.

Die nützliche Frage ist also nicht, ob die Signatur gültig ist, denn eine kaputte Signatur stoppt die Installation ohnehin. Sie ist, wessen Signatur Sie von nun an vertrauen wollen. Ein gestohlener Signaturschlüssel ist schlimmer als ein gestohlenes Paket, weil der Angreifer noch lange nach der ersten schlechten Veröffentlichung gültige Metadaten erzeugt. Rotation ist die einzige Reparatur, und sie hängt davon ab, dass der Anbieter einen neuen Schlüssel über einen Kanal veröffentlicht, den Sie unabhängig prüfen können.

Deshalb verdient die Schlüsselidentität so viel Aufmerksamkeit wie die Repositorium-URL. Ein Schlüssel aus einer Adresse in einer alten Forumsantwort belegt nichts über den Herausgeber, während HTTPS den Transport zu demjenigen schützt, der am Telefon geantwortet hat. Transportsicherheit und Herausgeberidentität sind getrennte Fragen, und nur die erste löst ein Zertifikat.

Begrenzen Sie den Schlüssel auf die Quelle, nicht auf das System

Modernes APT akzeptiert eine quellenspezifische Signed-By-Referenz. Ein vom Betreiber verwalteter Schlüssel kann unter /etc/apt/keyrings/ liegen, und der Quelleneintrag benennt den Schlüssel, der dieses Archiv beglaubigen darf. Das ist enger, als denselben Schlüssel in eine global vertrauenswürdige Menge zu werfen, wo er für Quellen bürgen kann, die Sie nie zulassen wollten. Folgen Sie der installierten APT-Version und den aktuellen Anweisungen des Anbieters, statt Fragmente aus verschiedenen Generationen von Anleitungen zu mischen.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

Beheben Sie einen Signaturfehler niemals, indem Sie die Prüfung abschalten oder ein unbekanntes Archiv als vertrauenswürdig markieren. Das tauscht einen sichtbaren Fehler gegen einen unsichtbaren, und der unsichtbare bleibt, bis jemand die Quellenliste prüft. Wenn der Schlüssel nicht passt, besteht die richtige Lösung darin, den richtigen Schlüssel zu finden, nicht die Prüfung zu entfernen.

Holen Sie die Repositorium-Details und die Schlüsselidentität beim Projekt oder bei einem verwalteten Administrator ein. Ein aus einem Blogbeitrag kopierter Schlüssel ist eine Behauptung über Urheberschaft, kein Beleg dafür. Wenn ein Anbieter einen Rotationskanal veröffentlicht, notieren Sie ihn zusammen mit dem Schlüssel, denn dieser Kanal ermöglicht die nächste Rotation.

Quellen-Pinning ist keine Paket-Allowlist

Einen Schlüssel auf eine Quelle zu beschränken begrenzt, welches Archiv er beglaubigen kann, nicht welche Pakete dieses Archiv veröffentlichen darf. Das Repositorium kann weit mehr liefern als den gewünschten VPN-Client, und die Kandidatenauswahl und Prioritäten von APT entscheiden, welche zulässige Version gewinnt. Prüfen Sie die vorgeschlagene Transaktion vor der Bestätigung, einschließlich der Abhängigkeitsliste, denn Abhängigkeiten kommen aus demselben Archiv. Ein Schlüsselumfang kann ’nur dieses Paket’ nicht ausdrücken.

Wenn Sie stärkere Kontrolle brauchen, drücken Sie sie als Richtlinie über Paketnamen oder -versionen aus und halten Sie diese Richtlinie unter Konfigurationsverwaltung. Eine Transaktion zu lesen dauert eine Minute; ein unerwartetes Paket sechs Monate später zu entdecken erfordert eine Prüfung.

Unerwartete Pakete sind der Moment zum Anhalten statt zum Weitergehen, und die Frage an den Archivinhaber ist, warum sie nötig sind. Ein Repositorium, das ein Dutzend Pakete um einen Client veröffentlicht, ist für einen Anbieter einer Desktop-Suite normal. Es ist auch eine größere Fläche, als die Installationsanleitung nahelegte, und genau dieser Teil ist es wert, festgehalten zu werden. Keines der beiden Ergebnisse ist ein Grund, der Signatur zu misstrauen; beide sind Gründe, aufzuschreiben, was Sie akzeptiert haben.

Halten Sie die Autorität und ihre Entfernung fest

Notieren Sie den Archivinhaber, die unterstützte Betriebssystemversion, den Schlüsselrotationskanal und das Entfernungsverfahren. Diese vier Fakten braucht ein Nachfolger, wenn der Client ausläuft oder der Anbieter seinen Schlüssel rotiert. Ohne sie erbt die nächste Person eine Quellenzeile und eine Schlüsseldatei ohne jede Geschichte.

Das Entfernen ist der Schritt, der übersprungen wird, also schreiben Sie ihn schon bei der Installation auf. Löschen Sie den Quelleneintrag und seinen eigenen Schlüssel zusammen, und prüfen Sie vor dem Löschen der Datei, ob dieser Schlüssel anderswo referenziert wird. Ein geteilter Schlüssel, der ohne diese Prüfung gelöscht wird, verwandelt eine Aufräumaktion in einen unabhängigen Ausfall, und das ist das schlechteste Ergebnis für eine Routinänderung. Bestätigen Sie dann, dass gewöhnliche Aktualisierungen noch aufgelöst werden, nachdem der Eintrag weg ist.

Eines bleibt, nachdem das Repositorium entfernt wurde: Jedes bereits daraus installierte Paket läuft weiter, bis etwas es ersetzt. Die ehrliche Frage ist, welche Autorität Sie hinzugefügt haben und wie eng ihre Rolle gefasst war.

Ähnliche Artikel