ubuntuusers.de

noisefloor schrieb:

Hallo,

also jedenfalls

Der Ordner /etc/apt/keyrings/ ist der einzig vernünftige Ort zu Ablage von Schlüsseln von Fremdquellen und nur dieser wird daher in diesem Artikel weiter betrachtet.

deb [signed-by=/etc/apt/keyrings/schluessel.gpg] http://example.org/linux/deb/ stable main

funktioniert das einwandfrei. Habe ich neulich für eine Fremdquelle unter 22.04 so gemacht.

Natürlich funktioniert das. Die Frage ist nur, wie man das Drumrum am besten macht, gerade im Hinblick auf gpg.

Hallo,

Die Frage ist nur, wie man das Drumrum am besten macht, gerade im Hinblick auf gpg.

? - was meinst du damit? Um den Artikel praktisch umzusetzen braucht man zwei Sachen: arbeiten mit Root-Rechten (um die Schlüsseldatei ins Verzeichnis zu kopieren) und einen Editor mit Root-Rechten bedienen, um die Datei in /etc/apt/sources.list.d/ anzulegen bzw. zu editieren.

Gruß, noisefloor

Nein, man brauch ggf. mehr, siehe den dearmor-Kram von gpg. Hier hat kb meinen Artikel (zurecht?) kritisiert und die Baustelle aufgemacht.

Und bei kB steht jetzt wieder diese Baustelle an erster Stelle.

Hallo Ihr Lieben,

Ich finde die 6 Punkte unter Grundlagen sehr gut gemacht ... Hut ab.

Dem darauffolgenden Satz (tolles Ergebnis meiner früheren (Überzeugungs)Mühen 😉 )

Der Ordner /etc/apt/keyrings/ ist der einzig vernünftige Ort zu Ablage von Schlüsseln von Fremdquellen ...

könnte man vielleicht noch "Fazit: " voranstellen.

müssen die Besitzverhältnisse und Dateiberechtigungen geregelt werden

Das klingt so nach einer Aufgabe, die man immer noch zusätzlich machen muss. Aber wenn man die Schlüssel so anlegt, wie überall vorgeschlagen, gibt es doch gar nichts mehr zu tun.

Um zu verstehen, was der dann folgende Befehl deutlich machen soll (z.B. wozu die geschweifte Klammer), musste ich mehrfach durch meine Gehirnwindungen. Vielleicht einfacher (dann gibt's auch keine Fehlermeldung mehr) so:

$ ls -l /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d/ /etc/apt/keyrings/   ##   auch die Option -a kann weg

oder besser erläutern, oder eher gleich weglassen. Das frisst nur Energie ohne besonderen Nährwert.
Ich fände es an der Stelle auch besser, Befehl und Ergebnis in einen Block zu setzen, denn es geht ja um eine Verdeutlichung, und nicht um einen Befehl, den man ausführen soll. Vor den Befehl dann ein '$' setzen.

Als Beispiel für dem Umgang mit Schlüsseln von Fremdquellen wird hier das Repositorium von Mozilla verwendet.

Das fehlt wohl noch.

karzer schrieb:

Ich habe ihn nun verschoben. Bin gespannt, was Du daraus machst!

Meine Überarbeitung hat wegen einigen erforderlichen Unterbrechungen leider länger gedauert als ursprünglich erwartet, aber nun betrachte ich sie als beendet und stelle den Text zur Diskussion.

kB schrieb:

Meine Überarbeitung hat wegen einigen erforderlichen Unterbrechungen leider länger gedauert als ursprünglich erwartet, aber nun betrachte ich sie als beendet und stelle den Text zur Diskussion.

Mein Ergänzungsvorschlag ist inzwischen hier gelandet und dessen Korrektur hier.

Und das hier gilt größtenteils auch noch.

UlfZibis schrieb:

[…] Mein Ergänzungsvorschlag ist inzwischen hier gelandet und dessen Korrektur hier.

Wurde von mir gelesen und verworfen, da Skype nichts mit diesem Artikel zu tun hat und die vorgeschlagene Prozedur ohnehin fehlerhaft ist, u.a. weil apt-key verwendet wird.

Und das hier gilt größtenteils auch noch.

Wurde ebenfalls bereits beantwortet und als unzutreffend verworfen.

kB schrieb:

Wurde von mir gelesen und verworfen, da Skype nichts mit diesem Artikel zu tun hat und die vorgeschlagene Prozedur ohnehin fehlerhaft ist, u.a. weil apt-key verwendet wird.

Mein Vorschlag ist, ganz allgemein eine Anleitung in den Artikel aufzunehmen, wie man falsch abgelegte Schlüssel an die richtige Stelle bugsiert, da dies ein häufig auftretender Fall sein wird. Meine Lösung ist ein Vorschlag, und kann gerne durch eine andere ersetzt werden. Es geht dabei auch nicht um Skype an sich, es sollte nur als Beispiel dienen. Und apt-key delete ist ein weiterhin zulässiger Befehl. Wie soll man denn sonst den Schlüssel aus dem falschen Ort entfernen?

Und das hier gilt größtenteils auch noch.

Wurde ebenfalls bereits beantwortet und als unzutreffend verworfen.

Und wo findet man diese Antwort bitte?

UlfZibis schrieb:

[…] Mein Vorschlag ist, ganz allgemein eine Anleitung in den Artikel aufzunehmen, wie man falsch abgelegte Schlüssel an die richtige Stelle bugsiert

Die allgemeine Anleitung steht bereits im Artikel unter FAQ. In einem Artikel für Fortgeschrittene gehe ich natürlich nicht auf die Befehle cp, mv, rm etc. ein, sondern setze diese Grundlagen voraus.

Wie soll man denn sonst den Schlüssel aus dem falschen Ort entfernen?

Wie es in den FAQ steht: Man löscht die Datei.

[…] Und wo findet man diese Antwort bitte?

Im Artikel. Die aktuelle Fassung lesen musst Du schon selber. Über frühere Fassungen werde ich nicht diskutieren.

kB schrieb:

Die allgemeine Anleitung steht bereits im Artikel unter FAQ. In einem Artikel für Fortgeschrittene gehe ich natürlich nicht auf die Befehle cp, mv, rm etc. ein, sondern setze diese Grundlagen voraus.

Ja stimmt, jedoch seeehr allgemein. Man muss sich dann die nötigen Befehle von verschiedenen Wiki-Seiten zusammen suchen. Da ist die Gefahr groß, dass man dabei auf die bequemen Befehle apt-key finger, apt-key export und apt-key del (die ja auch noch wunderbar funktionieren und ich auch nicht verstehe, was in dem Anwendungsfall gegen sie spricht) stößt, zumal man im Artikel GnuPG genau die Befehls-Kombi (zum Auslesen des später benötigten Fingerprints)

gpg --list-keys --keyring /etc/apt/trusted.gpg.d/mozillateam-ubuntu-ppa.gpg 

nicht findet, und erst nach längerem rumprobieren herausfindet, dass die auch nur funktioniert, wenn man den vollen Pfad angibt. Also warum nicht das Prozedere zum Nutzen der Leser einfach mal exemplarisch aufzeigen?

Wie es in den FAQ steht: Man löscht die Datei.

Die Datei /etc/apt/trusted.gpg also einfach löschen, auch wenn da außer dem zu löschenden noch andere Schlüssel drin enthalten sind ???

Dann verstehe ich nicht, warum Du in den Beispielen im Artikel ungewöhnliche Dateinamen und ohne Extension verwendest, statt die Vorgaben aus dem Debian-Wiki (sollte auch in die Link-Liste) zu verwenden. also z.B. "mozillateam-ubuntu-ppa-jammy.list" und "mozillateam-ubuntu-ppa.gpg".

Und dann mal eine generelle Frage. Würdest Du nun sagen, dass man Schlüssel aus den doch von Canonical verwalteten Launchpad-Quellen nicht (mehr) als sicher betrachten kann, sie deshalb auch nicht mehr in /etc/apt/trusted.gpg.d/ ablegen darf? Das würde doch bedeuten, dass alle Lauchpad-Seiten nicht mehr up-to-date sind, denn da wird überall add-apt-repository vorgegeben.

Die Erläuterungen zur Ausgabe von ls -al /etc/apt/trusted.gpg{,.d/} /etc/apt/keyrings/ finde ich jetzt ziemlich klasse. 👍

Dennoch fände ich es besser so in einem Block zusammengefasst, denn es geht ja um eine Verdeutlichung, und nicht um einen Befehl, den man ausführen soll:

$ ls -al /etc/apt/trusted.gpg{,.d/} /etc/apt/keyrings/
ls: Zugriff auf '/etc/apt/trusted.gpg' nicht möglich: Datei oder Verzeichnis nicht gefunden
/etc/apt/keyrings/:
insgesamt 12
drwxr-xr-x 2 root root 4096 Mär 26 16:52 .
drwxr-xr-x 8 root root 4096 Mär 26 16:47 ..
-rw-r--r-- 1 root root  417 Mär 26 16:52 Mozilla-Team

/etc/apt/trusted.gpg.d/:
insgesamt 16
drwxr-xr-x 2 root root 4096 Okt 14 11:53 .
drwxr-xr-x 8 root root 4096 Okt 12 14:54 ..
-rw-r--r-- 1 root root 2794 Okt 12 14:58 ubuntu-keyring-2012-cdimage.gpg
-rw-r--r-- 1 root root 1733 Mär 27  2021 ubuntu-keyring-2018-archive.gpg

UlfZibis schrieb:

[…] fände ich es besser so in einem Block zusammengefasst

Das ist manchmal im Forum zweckmäßig, aber nicht generell und im Wiki nicht Usus.

denn es geht ja um eine Verdeutlichung

Nein. Wie kommst Du auf diese Vermutung?

und nicht um einen Befehl, den man ausführen soll

Es ist ein Testbefehl, den der verantwortungsbewusste Administrator auf seinem System durchaus ausführen soll. Wenn man immer alles richtig macht, wird man natürlich keine Fehler finden. Aber auch sorgfältig arbeitende Leute machen nicht immer alles richtig und es ist daher sinnvoll, die eigene Arbeit z.B. mit diesem Befehl zu kontrollieren.

UlfZibis schrieb:

[…] man im Artikel GnuPG genau die Befehls-Kombi (zum Auslesen des später benötigten Fingerprints)

gpg --list-keys --keyring /etc/apt/trusted.gpg.d/mozillateam-ubuntu-ppa.gpg 

nicht findet […]

Im Artikel GnuPG findet man explizit diesen Befehl als Beispiel:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --list-keys 

Die vom Leser verlangte Transferleistung, dass es mit einem anderen Schlüsselbund nach Austausch des Dateinamens genauso funktioniert, erscheint mir nicht als unzulässige Überforderung.

Also warum nicht das Prozedere zum Nutzen der Leser einfach mal exemplarisch aufzeigen?

Das Prozedere zur Anzeige von Schlüsseln mit deren Fingerprint bei APT unterscheidet sich in keiner Weise von der allgemeinen Methode, und diese ist im zuständigen Artikel GnuPG (der ja als Wissen vorausgesetzt wird) beschrieben.

Wie es in den FAQ steht: Man löscht die Datei.

Die Datei /etc/apt/trusted.gpg also einfach löschen, auch wenn da außer dem zu löschenden noch andere Schlüssel drin enthalten sind ???

Wenn man alle noch benötigten Schlüssel exportiert und einzeln unter /etc/apt/trusted.gpg.d/ (was die modernere Variante ist) hinterlegt hat, kann man /etc/apt/trusted.gpg löschen.

Dann verstehe ich nicht, warum Du in den Beispielen im Artikel ungewöhnliche Dateinamen

Damit meinst Du konkret „/etc/apt/sources.list.d/DATEI.list“? Was empfindest Du an diesem generischen Ausdruck ungewöhnlich? Der in Versalien geschriebene Teil „DATEI“ kann durch einen beliebigen Text ersetzt werden. Dieser Umstand wird im UbuntuUsers-de-Wiki üblicherweise genau so gekennzeichnet.

und ohne Extension verwendest, statt die Vorgaben aus dem Debian-Wiki (sollte auch in die Link-Liste) zu verwenden […]

Im Dateisystem eines Unix-artigen Betriebssystem gibt es keine Extensionen, es sei denn, ein Anwendungsprogramm erwartet spezielle Dateinamen wie z.B. APT bei den Dateien für die Paketquellen *.list. Welche Vorgaben aus dem Debian-Wiki meinst Du? (Ich sehe da nur willkürliche Beispiele.) Als Link kann ich aber das Debian-Wiki gerne aufnehmen.

Und dann mal eine generelle Frage. Würdest Du nun sagen, dass man Schlüssel aus den doch von Canonical verwalteten Launchpad-Quellen nicht (mehr) als sicher betrachten kann, sie deshalb auch nicht mehr in /etc/apt/trusted.gpg.d/ ablegen darf?

Die PPAs auf Launchpad werden in der Regel nicht von Canonical verwaltet. Canonical stellt nur eine Plattform bereit, auf der Dritte in eigener Verantwortung Paketquellen errichten können. Das sind allesamt Fremdquellen und genießen damit nicht automatisch dasselbe Vertrauen, welches man Canonical entgegenbringen muss, wenn man Ubuntu verwenden will. Und aus genau diesem Grund gehören die Schlüssel von Fremdquellen wie Launchpad-PPAs nicht in die Dateien /etc/apt/trusted.gpg und /etc/apt/trusted.gpg.d/*.

Das würde doch bedeuten, dass alle Lauchpad-Seiten nicht mehr up-to-date sind, denn da wird überall add-apt-repository vorgegeben.

So ist es und genau da liegt der Hund begraben!

Die Verwendung von add-apt-repository und apt-key war immer nur vorgesehen für Paketquellen, denen man uneingeschränkt vertraut. In der Regel sind dies nur die offiziellen Paketquellen der Distribution und eventuell noch spezielle eigene oder die des eigenen Arbeitgebers. Die ungenierte missbräuchliche Verwendung dieser Befehle für öffentliche zusätzliche Paketquellen in Verantwortung Dritter ist die Ursache, warum diese Befehle jetzt als "depreciated" gebrandmarkt sind.

Auf Linuxnews gibt es nun einen Artikel zur Schlüsselverwaltung:

• Debian 12 und Repositories aus dritter Hand

Dort steht geschrieben:

Wie in der Warnung oben zu sehen ist, empfiehlt apt, diese Schlüssel anstatt wie bisher in /etc/apt/trusted.gpg abzulegen, das nun in /etc/apt/trusted.gpg.d zu tun. Im Debian Wiki steht dazu allerdings, das Hinzufügen von OpenPGP-Schlüsseln zu /etc/apt/trusted.gpg oder /etc/apt/trusted.gpg.d sei gleichermaßen unsicher. Dort wird /usr/share/keyrings empfohlen.

Begründet wird es damit:

Der Grund dafür ist, dass beim Hinzufügen eines OpenPGP-Schlüssels zum Signieren eines Repositorys zu einem der beiden Verzeichnisse dem Schlüssel von apt bedingungslos auch bei allen anderen auf dem System konfigurierten Repositorys vertraut wird, die über keine signed-by-Option verfügen. Infolgedessen kann jedes inoffizielle APT-Repository, dessen Signierschlüssel zu /etc/apt/trusted.gpg oder /etc/apt/trusted.gpg.d hinzugefügt wurde, jedes Paket auf dem System ungefragt aktualisieren oder ersetzen.