„Warning: apt-key is deprecated“ Meldung verstehen und lösen beim hinzufügen neuer Paketquellen

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

Diese Fehlermeldung erscheint seit einiger Zeit, wenn man versucht, einen neuen GPG-Schlüssel hinzuzufügen. Bei Drittanbieter-Paketquellen von APT-Paketen wird meist der öffentliche Schlüssel heruntergeladen und direkt an apt-key add übergeben, beispielsweise so:

pi@pi:~ $ wget -q -O - https://download.bell-sw.com/pki/GPG-KEY-bellsoft | sudo apt-key add -
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

Was machen wir da überhaupt?

Per APT verteilte Softwarepakete werden signiert. Damit soll sichergestellt werden, dass ihr wirklich die originalen Pakete von der jeweiligen Organisation wie z.B. Debian erhaltet. Wie das im Detail funktioniert, hängt mit asymmetrischer Verschlüsselung und der Funktionsweise von PGP zusammen. Das würde hier den Rahmen sprengen. Wir belassen es daher an der Stelle dabei, dass sich mit der Signatur die Integrität der Pakete sicherstellen lässt – was grundsätzlich eine sinnvolle Sache ist und die Sicherheit erhöht.

Mit apt-key add speichert ihr den öffentlichen Schlüssel der jeweiligen Organisation auf eurem Pi oder Server und vertraut ihm damit. Ansonsten hätte das System kein Vertrauensverhältnis – die Installation von Paketen aus nicht vertrauenswürdigen Quellen würde abgewiesen. Kann man selbst testen, in dem man eine Drittanbieter-Paketquelle hinzufügt, ohne vorher deren öffentlichen Schlüssel zu importieren.

Warum ist apt-key dann veraltet („deprecated“)?

Doch warum ist apt-key nun veraltet? Der Grund liegt in der Art und Weise, wie apt mit den Schlüsseln umgeht: Fügt ihr einen neuen Schlüssel mit apt-key hinzu, wird dieser in einen Ordner von vertrauenswürdigen Schlüsseln (konkret /etc/apt/trusted.gpg.d) abgelegt. Wenn man ein Paket installiert, prüft apt, ob es von irgendjemandem signiert wurde, dessen Schlüsseln wir vertrauen. Es wird nicht vorher abgefragt, ob der Schlüssel zu der Paketquelle passt.

Das ist zwar immer noch sicherer als gar keine Signaturen zu verwenden, aber es schwächt die Sicherheit. Besser wäre es, wenn ein Schlüssel nur für das dazugehörige Repository akzeptiert wird. Also eine 1:1 Beziehung, statt eines generellen, bedingungslosen Vertrauensverhältnisses. Aus diesem Grunde wurde apt-key als veraltet markiert, damit man auf dieses neue Verfahren wechselt.

Seit Debian 11 bzw Ubuntu 22.04 ist apt-key nur als veraltet markiert und daher weiterhin verfügbar. Allerdings ist das die letzte Hauptversion! Mit der nächsten Version von Debian bzw. Ubuntu wird es aller Voraussicht nach entfernt. Ich werde es daher in den Beiträgen nicht mehr einsetzen und ihr solltet es möglichst auch nicht mehr tun.

Wenn apt-key veraltet ist, wie füge ich dann einen Schlüssel hinzu?

Zunächst braucht es einen Ordner: /etc/apt/trusted.gpg.d sollte nicht verwendet werden, sonder ein eigener Ordner. Dieser ist frei Wählbar, ein sinnvoller Pfad könnte z.B. /usr/local/share/keyrings sein.

sudo mkdir /usr/local/share/keyrings

Als nächstes brauchen wir den öffentlichen PGP-Schlüssel. Der wird wie zuvor heruntergeladen, aber in eine Datei. Es macht an der Stelle Sinn, gleich mit file zu prüfen, ob es wirklich ein PGP-Key ist. Nicht von old verwirren lassen, „PGP public key block Public-Key (old)“ ist in Ordnung.

$ wget -q -O key.gpg https://download.bell-sw.com/pki/GPG-KEY-bellsoft
$ file key.gpg
key.gpg: PGP public key block Public-Key (old)

Nun müssen wir uns einen Schlüsselring erstellen, den wir APT übergeben können:

$ gpg --no-default-keyring --keyring ./tmp.gpg --import key.gpg
gpg: key 32E9750179FCEA62: public key "BellSoft LLC <info@bell-sw.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

$ gpg --no-default-keyring --keyring ./tmp.gpg --export --output bell-sw.gpg

$ rm tmp.gpg key.gpg

Fertig ist bell-sw.gpg, der hier auch gleich einen sprechenden Name zur Zuordnung erhalten hat. Diesen verschieben wir nun in das zuvor erstellte Verzeichnis:

sudo mv bell-sw.gpg /usr/local/share/keyrings

Auf den verweist du nun im Eintrag deiner deb-Paketquelle. Es empfiehlt sich, eine Liste pro Repository/Hersteller in /etc/apt/sources.list.d anzulegen, die auf .list endet. In meinem Beispiel lege ich also /etc/apt/sources.list.d/bell-sw.list an. Im normalen Paketquellen-Eintrag fügt man zwischen deb und der URL folgendes ein:

[signed-by=/usr/local/share/keyrings/bell-sw.gpg]

Beispiel:

deb [arch=amd64 signed-by=/usr/local/share/keyrings/bell-sw.gpg] https://apt.bell-sw.com/ stable main

Dies ist natürlich entsprechend der Architektur, Paketquellen-URL und ggf. des von dir gewählten Pfades anzupassen.

Nun kannst du die Paketquellen ganz normal via sudo apt update aktualisieren, damit sich apt den Paketindex aus dem neu hinzugefügten Repository laden kann. Hier sollte euer Repository (im Beispiel apt.bell-sw.com) gelistet sein und keine Fehlermeldung erscheinen.

$ sudo apt update
Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
Hit:2 http://deb.debian.org/debian bullseye InRelease
Hit:3 http://archive.raspberrypi.org/debian bullseye InRelease
Hit:4 http://deb.debian.org/debian bullseye-updates InRelease
Get:5 https://apt.bell-sw.com stable InRelease [4,166 B]
Get:6 https://apt.bell-sw.com stable/main arm64 Packages [18.2 kB]
Fetched 22.4 kB in 2s (12.6 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.

Leave a Reply