ubuntuusers.de

trollsportverein schrieb:

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

Sehr gut kurz und knapp formuliert.

Allerdings genau haben die den Debian Wiki-Artikel auch nicht gelesen, denn da wird für manuell verwaltete Schlüssel /etc/apt/keyrings empfohlen, und /usr/share/keyrings nur für paketverwaltete Schlüssel.

Danke für's teilen.

Ich habe beim Testen noch einen seltenen Sonderfall entdeckt, der allerdings die Paketverwaltung total lahmlegen kann und deshalb im Artikel berücksichtigt werden muss. Ich werde das tun, sobald ich ihn selbst verstanden habe. Die Freigabe der Baustelle wird sich daher leider nochmals verzögern.

Nach bisherigem Erkenntnisstand ist es nicht in allen Fällen möglich, auf die Datei /etc/apt/trusted.gpg zu Gunsten von /etc/apt/trusted.gpg.d/ zu verzichten.

Hier noch ein Trick, um dem penetranten Paketanbieter WinzigWeich das "verbotene" Benutzen von /etc/apt/trusted.gpg zu vereiteln.

Hallo,

hab mir gestern den Abschnitt "Grundlagen" des Baustellen-Artikels mal genauer durchgelesen, weil ich darüber gestolpert bin, dass es je nach Paketersteller bzw. Fremdquelle unterschiedliche Anleitungen gibt, wie man die Schlüssel importieren bzw. verwenden soll (konkret: Ablegen in /etc/apt/trusted.gpg.d/ vs. /etc/apt/keyrings)

Fazit: kB beschreibt das mal wieder super detailliert - und der Übersicht-Teil ist auch wirklich sehr übersichtlich. Ich glaub ich habs verstanden 😉

Mein Vorschlag wäre, aus dem Baustellen-Artikel zwei Artikel zu machen.

1. Grundlagen

2. Rest

Die "Vorsicht-Schilder" und Begriffe wie "Forderung" in dem Artikel sind mir ein paar zu viele bzw. zu absolut und wirken auf mich fast "moralisch". Das hätte ich gerne etwas reduziert auf einen, vielleicht zwei Hinweise. Und ansonsten möglichst technisch bleiben. Vielleicht kann ein Teil davon nach Fremdquellen wandern, da wird das Thema ja auch schon angesprochen. Bei dem ganzen "Vertrauens-Thema" wäre die Überlegung, ob so etwas in den GnuPG-Artikel kann oder in einen allgemeineren Artikel, der so Vertrauensverhältnis-Geschichten im Internet erklärt. Ist ja ein generelles Thema (auch bspw. bei Zertifikaten / CAs) und betrifft nicht nur apt. Würde dem sonst eher technisch und sachlich gehaltenen Artikel gut tun.

Hier noch konkreten Anmerkungen zu den einzelnen Abschnitten bis inkl. "Schlüssel beschaffen".

Die Wissensbox kann bei einer Aufteilung imho reduziert werden. Für das Verstehen der Grundlagen muss man z.B. nicht wissen, wie GnuPG funktionieret.

Die Einleitung find ich gut.

In der 1. Hinweisbox würde ich ergänzen "nicht mehr anwenden".

In der 2. Hinweisbox ist mir der zweite Punkt (besonders "Fehlerfreiheit" zu überflüssig). Das gilt für alle Software, auch ohne Fremdquellen.

In der 3. Hinweisbox der dritte Punkt ("Gewissen") scheint mir für einen technischen Artikel etwas flapsig. Hab aber gerade keinen konkreten Vorschlag.

Orte im Dateisystem:

"Auch diese Schlüssel haben globale Gültigkeit, in diesem Ordner dürfen deshalb keine Schlüssel von Fremdquellen abgelegt sein oder das eigene System muss als kompromittiert gelten." Das finde ich zu absolut - und es widerspricht vielen globalen Anleitungen. Auch wenn das deine Überzeugung ist, kB , so sollte zumindest erwähnt werden, dass einige Anleitungen den Schlüssel dort ablegen. Dann kann man schreiben "Besser ist allerdings /etc/apt/keyrings" ...

Rückfrage: Was passiert denn, wenn ein Schlüssel in /etc/apt/trusted.gpg.d angelegt wird, die Fremdquellen via signed-by= dann aber einzeln auf keys referenzieren? Das wird hier nur gestreift. Zitat "sofern diese nicht selbst einen ganz bestimmten Schlüssel vorschreibt." Das heißt, es wäre kein Problem, aber trotzdem verwirrend?

"Der Ordner /etc/apt/keyrings/ wird von APT zur Speicherung von Schlüsseln vorgeschlagen. Hier abgelegte Schlüssel haben keine globale Gültigkeit und werden von APT überhaupt nicht beachtet, es sei denn, man verknüpft explizit eine Paketquelle mit einem dieser Schlüssel." → perfekt erklärt, das war gestern der erhellende Faktor. Vielen Dank!

Da hier im Artikel nur auf /etc/apt/keyrings genauer eingegangen wird, braucht imho /etc/apt/trusted.gpg{,d} nicht nach Rechten überprüft werden. Das wurde ja hier gar nicht angefasst.

Die Einleitung in "Fremdquelle aktivieren" gehört imho nach Fremdquellen

"Auf den PPA-Seiten des Mozilla-Teams verstecken sich die Angaben zum Schlüssel hinter dem Link "Technical details about this PPA", den man erst anklicken muss." Gilt das nicht für alle PPAs bzw launchpad?

Soweit mal für heute.

Viele Grüße

BillMaier

EDIT: kleine Korrektur

EDIT: crosslink https://forum.ubuntuusers.de/post/9388694/

BillMaier schrieb:

Hallo,

Bin da mit mit allem, was Du schreibst voll einverstanden, auch wenn ich nicht alles bis in die Tiefe nachvollzogen habe.

"Der Ordner /etc/apt/keyrings/ wird von APT zur Speicherung von Schlüsseln vorgeschlagen. Hier abgelegte Schlüssel haben keine globale Gültigkeit und werden von APT überhaupt nicht beachtet, es sei denn, man verknüpft explizit eine Paketquelle mit einem dieser Schlüssel." → perfekt erklärt, das war gestern der erhellende Faktor. Vielen Dank!

Super Formulierung, ich würde vielleicht "überhaupt" durch "erstmal" ersetzen und "zur Speicherung von Fremd-Schlüsseln" schreiben

Da hier im Artikel nur auf /etc/apt/keyrings genauer eingegangen wird, braucht imho /etc/apt/trusted.gpg{,d} nicht nach Rechten überprüft werden. Das wurde ja hier gar nicht angefasst.

👍

"Auf den PPA-Seiten des Mozilla-Teams verstecken sich die Angaben zum Schlüssel hinter dem Link "Technical details about this PPA", den man erst anklicken muss." Gilt das nicht für alle PPAs bzw launchpad?

In dem Zusammenhang fehlt mir eine nachvollziehbare Begründung, warum man der auf Launchpad hervorgehobenen Anleitung mittels add-apt-repository nicht folgen soll, sondern das Schlüsselgedöns kompliziert manuell einrichten soll. Kann doch nicht sein, dass Lauchpad da in tausenden von Fällen falsches anleitet.

Wie ist hier der Stand?

DJKUhpisse schrieb:

Wie ist hier der Stand?

Es gibt einen schwer zu fassenden Spezialfall, der erheblichen Ärger machen kann (und bei mir gelegentlich auch macht), und im Artikel noch nicht behandelt wird. Ich kämpfe um eine passende Formulierung, die voraus setzt, dass ich es selbst verstehe. Es wird mir diesem Artikel weitergehen bis zu einem hoffentlich baldigen Abschluss, aber manchmal habe ich Wichtigeres zu erledigen, Urlaub z.B.

https://www.michlfranken.de/ubuntu2310-das-kommt/ :

"Das bisherige Verfahren die PPAs in einer .list-Datei unter /etc/apt/sources.list.d/ zu verwalten und einen GPG Schlüsselring in /etc/apt/trusted.pgp.d zu speichern, wird als potenzielles Sicherheitsproblem erachtet, da GPG Schlüssel auf Systemebene hinzugefügt werden.

Dies wurde als potenzielles Sicherheitsproblem erkannt, da der GPG-Schlüssel auf Systemebene hinzugefügt wird. Dieser Mechanismus wird nun abgeschafft und stattdessen wird die Information über den GPG-Schlüssel in die sources.list des externen Repos selbst aufgenommen. Auf diese Weise wird der GPG-Schlüssel nur noch Pakete aus dem zugehörigen Repository akzeptieren."

Wie ist denn hier eigentich der Stand der Baustelle? Das Thema ploppt im Support ja immer mal wieder hoch.

Gruß, noisefloor

Ich finde auch, jetzt, mit dem Erscheinen der 5. (!) Ubuntu-Version, in der es dieses Problem gibt, könnten wir langsam einmal offizielle und unbedenkliche Richtlinien veröffentlichen. Und von der Fertigstellung dieses Artikels hängt eben die Anpassung der meisten Artikel und Vorlagen ab, die dieses Problem reproduzieren. Ich würde Dich daher bitten, kB, baldigst auf diese Baustelle zurückzukommen.

Der Artikel zeigt nach dem Satz

"Man kann nun den Schlüssel selbst per Protokoll HTTPS vom Keyserver herunter laden oder ihn sich über diese Befehle per Protokoll HKP beschaffen:"

das Beispiel

1

gpg --no-default-keyring --keyring /tmp/KEYRING --keyserver hkp://keyserver.ubuntu.com:80 --recv-key $Fingerprint

Es gibt auch noch HKPS, das soll, ähnlich wie HTTPS eine mit TLS gesicherte Variante von HTTP ist, ebenfalls eine mit TLS gesicherte Variant von HKP sein.

Ich habe mal diese Ratschläge gehört, die mir einleuchten (zumal viele Pakete nur über eine ungesicherte HTTP-Verbindung angeboten werden):

1. Zum Download von Schlüsseln HTTPS oder HKPS verwenden, niemals die ungesicherten Varianten,

2. Download immer nur von den Seiten der Paket-Maintainer, mindestens den Fingerabdruck des Schlüssels mit den vom Paket-Maintainer auf dessen Webseite veröffentlichten vergleichen.

Andernfalls kann einem unbemerkt entgehen, daß und wenn

1. ein MIM den Schlüssel beim Download austauscht und ein verändertes Paket mit dem zugehörigen Schlüsselpendant ausliefert - oder

2. auf dem Download-Server schon ein verändertes Paket liegt, das mit einem anderen Schlüssel signiert wurde und derzugehörige öffentliche Schlüssel dort oder anderswo ebenfalls zum Download angeboten wird.

Diese Regeln unterstellen, daß die Paketquellenmaintainer ihre privsaten Schlüssel wirklich geheim halten und sie ebenfalls sicherstellen, daß der veröffentlichte öffentliche Schlüssel und der zugehörige Fingerprint gegen Manipulatin auf ihrem Server effektiv gegen Manipulationen sichern.

Müßte man deshalb im Artikel nicht überall von HTTPS bzw HKPS sprechen, wo derzeit noch von den einfachen Varianten die Rede ist? Sollte dann nicht auch eine Warnung vor den ungesicherten Varianten ausgesprochen werden?

4-Elster-4 schrieb:

[…] HKPS […]

Danke für Deine Hinweise. Ich werde sie berücksichtigen, wenn ich die Arbeit an dieser zur Zeit ruhenden Baustelle wieder aufnehmen kann, momentan habe ich noch andere, mir wichtiger erscheinende Artikel in Arbeit.

Generell ist natürlich HKPS vor HKP zu bevorzugen, sofern die Server das beherrschen, was mir nicht für alle zutreffend scheint.

Hallo,

dieser Artikel befasst sich nur mit den Installations-Schlüsseln der Paketverwaltung, nicht mit anderen Schlüsselverwaltungen wie z.B. dem GNOME-Keyring. Deshalb denke ich, dass der Titel dieses Artikels entsprechend spezialisiert angepasst werden müsste.

Wer hier z.B. auf der Suche nach Information über das Zusammenspiel von ${HOME}/.gnome2/keyrings/ bzw. ${HOME}/.local/share/keyrings/ sucht, geht fehl. Ich z.B. bin auf der Suche danach, um hier darauf verweisen zu können.

Gibt es überhaupt einen Artikel, der z.B. das Zusammenführen solcher Schlüssel erklärt?

UlfZibis schrieb:

[…] dieser Artikel befasst sich nur mit den Installations-Schlüsseln der Paketverwaltung, nicht mit anderen Schlüsselverwaltungen wie z.B. dem GNOME-Keyring.

Ja.

Deshalb denke ich, dass der Titel dieses Artikels entsprechend spezialisiert angepasst werden müsste.

Es ist eine Unterseite zu APT. Was ist Dir an „apt/Schlüsselverwaltung" zu wenig speziell bzw. wieso siehst Du da eine besondere Verwechslungsgefahr mit Teilen von Gnome?

kB schrieb:

Es ist eine Unterseite zu APT. Was ist Dir an „apt/Schlüsselverwaltung" zu wenig speziell bzw. wieso siehst Du da eine besondere Verwechslungsgefahr mit Teilen von Gnome?

Oh, das ist mir nicht aufgefallen. Man muss also genau hinschauen, wenn man die "Schlüsselverwaltung" über die Wiki-Suche findet.