HTTPS und ein VPN authentifizieren nicht das Paket, das Sie installieren

Ein Update schlägt fehl, und der Vorschlag im Thread folgt einer bekannten Linie: Der Verkehr läuft über ein VPN, also muss der Download vertrauenswürdig sein, und die Signaturprüfung wird gelockert, um am Fehler vorbeizukommen. Zwei getrennte Ideen sind zu einem Satz verschmolzen. Verschlüsselung schützt einen Pfad zwischen Endpunkten; Authentifizierung entscheidet, ob die Bytes vom beabsichtigten Herausgeber stammen. Ein Tunnel liefert das erste und sagt nichts über das zweite.

Das Symptom ist meist ein Verifikationsfehler auf einem Host, in einem Repository, während alles andere normal aktualisiert wird. Diese Form sagt bereits, dass der Netzwerkpfad funktioniert und dass der Streit das Vertrauen betrifft.

Zwei Kontrollen, die verschiedene Fragen beantworten

Transportsicherheit beantwortet, wer am anderen Ende dieser Verbindung steht und ob jemand auf dem Pfad sie lesen oder verändern kann. Paketauthentifizierung beantwortet, ob dieses Artefakt von der von Ihnen konfigurierten Instanz veröffentlicht wurde, und sie muss ein Herunterladen über einen Spiegel überstehen, den Sie nicht kontrollieren.

Diese Fragen überschneiden sich nur an den Rändern. Ein korrektes Zertifikat auf einem Spiegel beweist, dass der Spiegel der Spiegel ist; es beweist nicht, dass der Spiegel unveränderte Herausgeberinhalte enthält. Ein signiertes Paket beweist, dass der Herausgeber es signiert hat; es sagt Ihnen nicht, dass das Netzwerk die neueste Version geliefert hat oder dass das Repository, auf das Sie gezeigt haben, das von Ihrer Organisation genehmigte ist.

Der Fehlermodus, den Leute durch Abschalten von Prüfungen erzeugen, ist ein dauerhafter Verlust der zweiten Garantie, eingetauscht gegen einen erfolgreichen Download. Dieser Tausch ist unsichtbar bis zu dem Tag, an dem er zählt.

Was apt tatsächlich authentifiziert

APT’s Modell ist eine authentifizierte Archivkette. Signierte Release-Metadaten führen per Prüfsumme zu den Paketindizes, und diese Indizes führen per Prüfsumme zu den einzelnen Paketdateien. Die Verifikation der Kette macht einen Spiegel unvertrauenswürdig, aber nutzbar: Der Spiegel kann ausliefern, was er will, und die Signatur der Metadaten entscheidet, ob APT es akzeptiert.

Das ist bewusst nicht dasselbe wie die Prüfung einer Maintainer-Signatur an jedem installierten Paket, und der Unterschied erklärt, warum «das Paket ist signiert» und «das Archiv ist authentifiziert» in Fehlerberichten synonym verwendet werden, obwohl sie Verschiedenes meinen.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

Lesen Sie die Ausgabe des Updates, nicht nur den Exit-Code. APT nennt das Repository, dessen Metadaten fehlgeschlagen sind, und dieser Name ist die Grenze, die zu untersuchen ist. Ein Repository, das ohne Signaturprüfung als vertrauenswürdig markiert ist, oder eine Übersteuerung für ein unsicheres Repository ist eine Konfigurationsentscheidung, die jemand getroffen hat und erklären können sollte.

Frische ist wieder eine eigene Eigenschaft. Eine gültig signierte Metadatendatei kann älter sein als die, die Sie letzte Woche gesehen haben, deshalb tragen Release-Metadaten ein Ablaufdatum, und deshalb kann ein Uhrproblem auf dem Client Verifikationsfehler erzeugen, die wie Schlüsselprobleme aussehen.

Was dnf5 getrennt prüft

Die RPM-Seite bietet zwei verschiedene Schalter, und sie zu verwechseln erzeugt dieselbe Fehlerklasse in die andere Richtung. Der eine steuert, ob Paketdateien eine gültige Signatur tragen müssen; der andere, ob Repository-Metadaten signiert sein müssen. Sie lassen sich unabhängig setzen, und ein System kann bei dem einen streng und bei dem anderen nachsichtig sein.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

Die Paketabfrage zeigt, wie die Signaturmetadaten der installierten Kopie aussehen, was ein nützlicher Realitätscheck gegen eine Konfigurationsdatei ist, die Strenge behauptet. Was sie Ihnen nicht sagt, ist die unterstützte Richtlinie der Distribution, und dieser sollten Sie folgen statt einer allgemeinen «GPG aktivieren»-Anweisung aus einem Forum.

Wo die beiden Verwalter sich unterscheiden, ist der Unterschied architektonisch und kein Zeichen, dass einer schwächer ist. Beide authentifizieren Herausgeberinhalte; sie setzen die Signatur an verschiedene Stellen der Kette.

Was der Tunnel hinzufügt und was nicht

Ein VPN kann eine erforderliche Route bereitstellen, Update-Verkehr von einem nicht vertrauenswürdigen Zugangsnetz fernhalten und verringern, was ein lokaler Beobachter sieht. Das sind echte betriebliche Vorteile, und keiner davon ist Herausgeberauthentifizierung.

HTTPS fügt seine eigene Garantie hinzu, und sie ist enger, als sie sich anfühlt. Es authentifiziert den TLS-Endpunkt, mit dem Sie sich verbunden haben. Ist dieser Endpunkt ein Spiegel, haben Sie den Spiegel authentifiziert, nicht den Archivinhalt, den er ausliefert. Genau das ist der Fall, für den die Kette signierter Metadaten existiert.

Keine der Kontrollen verspricht Verfügbarkeit. Ein Netzwerk kann die Lieferung verweigern, und ein authentifiziertes Objekt ist nicht automatisch das neueste. Nutzen Sie die Frische-Richtlinie des Paketverwalters selbst, statt sie aus dem Vorhandensein eines Schloss-Symbols abzuleiten.

Diagnostizieren Sie die Grenze, die versagt hat

Benennen Sie die Stufe, bevor Sie etwas ändern: DNS-Auflösung, den Proxy oder die Route, die Identität des TLS-Endpunkts, die Archivauthentifizierung, die Paketsignaturprüfungen oder die Installation. Jede hat eine eigene Fehlerform und einen eigenen Verantwortlichen.

Die Reparatur eines Netzwerkpfads sollte niemals beinhalten, einen unbekannten Signaturschlüssel für vertrauenswürdig zu erklären, Zertifikate zu ignorieren oder eine Repository-Konfiguration zu akzeptieren, um die Sie nicht gebeten haben. Wenn ein Schlüssel tatsächlich rotiert wurde, veröffentlicht die Distribution oder der Repository-Eigentümer den neuen Schlüssel über einen Kanal, den Sie überprüfen können, und das ist die anzuwendende Korrektur.

Schreiben Sie auf, welche Grenze versagt hat und wer sie verantwortet. Der nächste Update-Fehler wird an einer anderen Grenze liegen, und die Liste macht daraus eine Fünf-Minuten-Diagnose statt einer weiteren Debatte darüber, ob der Tunnel Updates sicher macht.