Artikel mit Tag solution

Lösung: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead

Was ist apt-key?

Die Man Pages beschreiben apt-key wie folgt:

apt-key is used to manage the list of keys used by apt to authenticate packages. Packages which have been authenticated using these keys will be considered trusted.

apt-key wird verwendet, um die Liste der Schlüssel zu verwalten, die von apt zur Authentifizierung von Paketen verwendet werden. Pakete, die mit diesen Schlüsseln authentifiziert wurden, werden als vertrauenswürdig eingestuft.

Der Vollständigkeit halber hier der Punkt zur "deprecated" Meldung:

update (deprecated)
Update the local keyring with the archive keyring and remove from the local keyring the archive keys which are no longer valid. The archive keyring is shipped in the archive-keyring package of your distribution, e.g. the ubuntu-keyring package in Ubuntu.

Note that a distribution does not need to and in fact should not use this command any longer and instead ship keyring files in the /etc/apt/trusted.gpg.d/ directory directly as this avoids a dependency on gnupg and it is easier to manage keys by simply adding and removing files for maintainers and users alike.

Was bedeutet apt-key is deprecated?

In der Fehlermeldung "apt-key is deprecated. Manage keyring files in trusted.gpg.d" sind zwei Meldungen versteckt:

Bisher wurden Schlüssel in trusted.gpg verwaltet. In Zukunft sollten die Schlüssel einzeln unter trusted.gpg.d verwaltet werden. Der Grund für das Abschaffen des alten Vorgangs ist die schlicht die Sicherheit.

Zusätzlich wird apt-key als veraltet eingestuft. Da es sich hier nur um eine Warnung handelt, kann diese bis jetzt auch einfach ignoriert werden. Im Prinzip möchte sie den Nutzer weg von apt-key hin zu gpg schubsen und genau das möchte ich hier zeigen.

Bei einem apt update wirft ein Ubuntu beispielsweise folgenden Warnungen in Bezug auf nodejs und yarn Repositorys

reading package lists... Done
W: https://deb.nodesource.com/node_16.x/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
W: https://dl.yarnpkg.com/debian/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Lösung -  Schlüssel aus trusted.gpg in trusted.gpg.d umziehen

Die Lösung für die oben aufgeführte Problematik ist das bereits erwähnte Umschichten von trusted.gpg zu trusted.gpg.d.

Zunächst werden die betreffenden Schlüssel aufgelistet:

sudo apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------
pub   rsa4096 2014-06-13 [SC]
      9FD3 B784 BC1C 6FC3 1A8A  0A1C 1655 A0AB 6857 6280
uid           [ unknown] NodeSource <gpg@nodesource.com>
sub   rsa4096 2014-06-13 [E]

pub   rsa4096 2016-10-05 [SC]
      72EC F46A 56B4 AD39 C907  BBB7 1646 B01B 86E5 0310
uid           [ unknown] Yarn Packaging <yarn@dan.cx>
sub   rsa4096 2016-10-05 [E]
sub   rsa4096 2019-01-02 [S] [expires: 2023-01-24]
sub   rsa4096 2019-01-11 [S] [expires: 2023-01-24]


Schlüssel in eine eigene Datei verschieben

Danach die letzten 8 Zeichen der zweiten Zeile unter pub kopieren. In diesem Fall ist das 6857 6280. Das Leerzeichen zwischen den Zahlen muss entfernt werden.
Der zukünftige Name kann beliebig gewählt werden, es liegt allerdings nahe, ihn nach dem installierten Paket bzw. Repository zu benennen:

sudo apt-key export 68576280 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/nodejs-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-key export 86E50310 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/yarn-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-get update

Nun sollten die Warnungen der Vergangenheit angehören.

Neue Schlüssel hinzufügen

Sollte ein neuer Schlüssel hinzugefügt werden, wird in Zukunft nicht mehr mit apt-key gearbeitet, sondern gpg verwendet werden.

Früher

curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | sudo apt-key add -


Heute

curl -sS https://download.spotify.com/debian/pubkey_7A3A762FAFD4A51F.gpg | sudo gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/spotify.gpg

 

Was bedeutet: WARNING apt does not have a stable CLI interface. Use with caution in scripts?

Beim Ausführen von Skripten auf einer Linux Konsole, die apt install beinhalten, taucht folgende Meldung auf: 

WARNING : apt does not have a stable CLI interface. Use with caution in scripts.

Doch warum wird eine Warnung angezeigt? Die Lösung ist relativ simpel.

Vor Jahren hatte ich mal eine Übersicht von apt vs. apt-get veröffentlicht. Ich habe sie euch unten noch einmal eingebunden.
Im Artikel ist zu lesen, dass apt unter anderem einen grafischen Fortschrittsbalken ausgibt.

Genau das ist einer der Gründe, warum das Kommandozeilentool bei der Verwendung in Scripten ein WARNING meldet. Denn diese Fortschritts-Ausgabe kann von Scripten fehlerhaft interpretiert werden und ist im Prinzip nur für Endnutzer gemacht, aber nicht wirklich für Skripte. Darum sollte hier eher auf apt-get zurückgegriffen werden.

Gleiches gilt übrigens auch für apt show programm-name. Hier sollte besser apt-cache show programm-name verwendet werden.

apt vs. apt-get
apt Kommando apt-get Kommando Funktion
apt install apt-get install Pakete installieren
apt remove apt-get remove Pakete deinstallieren
apt list --upgradable -- Anstehende Updates anzeigen
apt list dpkg list Pakete auflisten
apt purge apt-get purge Pakete und Konfiguration entfernen
apt update apt-get update Repository aktualisieren
apt upgrade apt-get upgrade Anstehende Pakete aktualisieren
apt full-upgrade apt-get dist-upgrade Anstehende Pakete aktualisieren und deinstallieren
apt autoremove apt-get autoremove Nicht benötigte Pakete deinstallieren
apt search apt-cache search Pakete suchen
apt show apt-cache show Paketdetails anzeigen
apt edit-sources -- sources.list editieren

Läuft nicht ganz rund – WSL2 mit Windows 10 2004 und VirtualBox

In der Vergangenheit hatte ich bereits über WSL2 berichtet und die neuen Funktionen, die damit einhergehen. Leider kommt es nach der Aktivierung von WSL2 unter Windows 10 2004 zu Problemen mit VirtualBox.

Microsoft sind Probleme bekannt und listet dies auch auf der betreffenden FAQ Seite auf.

Ich hatte beispielsweise in der Vergangenheit mit aktivem WSL2 Probleme meine vorhandene Linux Server Systeme zu starten, bereits beim Bootvorgang kam es zu Kernel Fehlern, welche das System ausbremsten.

Da waren Fehler wie VERR_NEM_VM_CREATE_FAILED oder VERR_NEM_MISSING_KERNEL_API_2

WSL1 kannte diese Probleme noch nicht, da es Hyper-V (Windows Hypervisor Plattform) nicht verwendete, WSL2 tut aber genau dies, was wiederum zu dubiosen Fehlermeldungen in Verbindung mit VirtualBox führt.

Schlimmer wurde es mit Ubuntu Desktop 20.04 unter VirtualBox, hier war es nicht mehr möglich ein apt update auszuführen, ohne Hash Fehler (Hash sum mismatch) zu erhalten.

Hash_sum_mismatch

WSL2 und VirtualBox entweder oder - Die Lösung

Zunächst solltet ihr für eine aktuelle Umgebung sorgen

  • Aktualisiert VirtualBox, die neueste September Version 6.1.14 hat eines der hier beschriebenen Probleme gelöst. Changelog-6.1#v14
  • Deaktiviert das  Feature Windows Feature "Plattform für virtuelle Computer", damit greift VirtualBox auf seine eigene Engine zurück

PlattformfuervirtuelleComputer

Nach einem Neustart sollten alle Probleme in VirtualBox in Verbindung mit Linux Installation und Fehlern wie "Hash sum mismatch" oder "failed to fetch store" der Vergangenheit angehören. Negativer Effekt, WSL2 funktioniert nun nicht mehr.

Zum besseren Verständnis eine Übersicht der einzelnen Funktionen

  • Hyper-V ist der Hypervisor von Microsoft.
  • Plattform für virtuelle Computer - Ermöglicht Unterstützung für virtuelle Maschinen und ist für WSL2 erforderlich.
  • Windows-Hypervisor-Plattform - Ermöglicht die Ausführung von Virtualisierungssoftware auf dem Windows-Hypervisor. Die Hypervisor-Plattform ist eine API, die Drittanbieter-Entwickler für die Verwendung von Hyper-V verwenden können, beispielsweise Oracle VirtualBox oder Docker.

 

WSL und VirtualBox zusammen verwenden

Wie bereits oben erwähnt ist momentan ein Zusammenspiel von VirtualBox und WSL2 nicht ohne Probleme möglich.

Wer dennoch beide System verwenden möchte, der hat momentan nur die möglich auf WSL1 downzugraden.

WSL-Ubuntu_18.04_LTS_downgrade

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

wsl --list –verbose

wsl --set-version kali-linux 1

dism.exe /online /disable-feature /featurename:VirtualMachinePlatform /norestart

 

WSL selbst sollte natürlich weiterhin in den Windows Einstellungen aktiv sein.

WindowsSubsystemfuerLinux