ubuntuusers.de

UlfZibis schrieb:

[…] das Zusammenspiel von ${HOME}/.gnome2/keyrings/ bzw. ${HOME}/.local/share/keyrings/

Wie soll dieses „Zusammenspiel“ denn aussehen?

Auf meinem System (24.04 neu installiert) habe ich gar keinen Ordner ~/.gnome2/, der schon schon durch seinen Namen zwar an gute Zeiten erinnert, aber eben auch veraltet klingt.

Ich vermute, dass die Nennung von ~/.gnome2/ im Artikel veraltet ist und eher ~/.local/share/keyrings/ gemeint ist, will das aber noch bei 20.04 überprüfen.

Bzgl. "gnome2" gab es wohl ja schon im Jahre 2020 einige Fragezeichen, aber da fehlen mir die Details.

kB schrieb:

Wie soll dieses „Zusammenspiel“ denn aussehen?

Letzteres wird bei Vorhandensein ggü. ersterem priorisiert.

Ich vermute, dass die Nennung von ~/.gnome2/ im Artikel veraltet ist und eher ~/.local/share/keyrings/ gemeint ist,

Ersteres wird von Signal Desktop verwendet, auch heute noch. Bei der Entrümpelung durch Neuerstellung meines HOME-Verzeichnisses habe ich tagelang rumgewurschtelt, um den Signal Desktop wieder zum Laufen zu kriegen, Ergebnis siehe: Signal Desktop (Abschnitt „Signal-Nachrichten-retten-bei-Neuinstallation“).

Ich vermute, dass in diesen Dateien bei mir noch andere Schlüssel als die von Signal drin sind. Insofern würde es mir helfen, wenn der Artikel 1. erklären würde, wie man das überprüft / die ausliest und 2., wie man die Schlüssel aus beiden Verzeichnissen evtl. zusammen führen kann.

In meinem originalen HOME gab es nur .gnome2/keyrings/. Im neu erstellten gab es dann plötzlich .local/share/keyrings/, welches das Auslesen des Signal-Schlüssels aus .gnome2/keyrings/ verhinderte.

kB schrieb:

[…] Ich vermute, dass die Nennung von ~/.gnome2/ im Artikel veraltet ist und eher ~/.local/share/keyrings/ gemeint ist, will das aber noch bei 20.04 überprüfen.

Ergebnis: Bei meinem alten 20.04 gibt es kein ~/.gnome2/.

Im Artikel sollte jemand die Befehle auf die aktuellen Verhältnisse anpassen und den Artikel für 24.04 testen.

BillMaier schrieb:

bei MATE liegen die Dateien hier:

~/.local/share/keyrings
~/.local/share/keyrings/login.keyring
~/.local/share/keyrings/user.keystore

Wäre interessant, […] welche Abweichungen für die einzelnen Derivate gelten.

Das gilt so jedenfalls auch beim Desktop Gnome für Ubuntu 20.04, 22.04 und 24.04. Ich sehe auch keinen Grund, warum es bei einem anderen Derivat – sofern das überhaupt gnome-keyring verwendet – anders sein sollte.

UlfZibis schrieb:

kB schrieb:

Wie soll dieses „Zusammenspiel“ denn aussehen?

Letzteres wird bei Vorhandensein ggü. ersterem priorisiert.

Das ist jedenfalls nicht falsch. Der Ordner ~/.local/share/keyrings/ ist seit Jahren vorgesehen zur Ablage dieser Schlüsselbündel.

Mich verwundert eher, dass unter bestimmten Umständen ~/.gnome2/keyrings/ überhaupt noch berücksichtigt wird. Da hat vermutlich jemand vergessen, eine veraltete Rückfalloption zu entfernen.

Ich vermute, dass die Nennung von ~/.gnome2/ im Artikel veraltet ist und eher ~/.local/share/keyrings/ gemeint ist,

Ersteres wird von Signal Desktop verwendet, auch heute noch. […]

Bizarr.

Ich vermute, dass in diesen Dateien bei mir noch andere Schlüssel als die von Signal drin sind. Insofern würde es mir helfen, wenn der Artikel 1. erklären würde, wie man das überprüft / die ausliest und 2., wie man die Schlüssel aus beiden Verzeichnissen evtl. zusammen führen kann.

Es ist nicht Aufgabe dieses Artikels, für Sonderfälle veraltetes Verhalten zu beschreiben. Das kann besser als Supportanfrage im zuständigen Forum diskutiert werden.

In meinem originalen HOME gab es nur .gnome2/keyrings/. Im neu erstellten gab es dann plötzlich .local/share/keyrings/, welches das Auslesen des Signal-Schlüssels aus .gnome2/keyrings/ verhinderte.

Bizarr.

kB schrieb:

Mich verwundert eher, dass unter bestimmten Umständen ~/.gnome2/keyrings/ überhaupt noch berücksichtigt wird. Da hat vermutlich jemand vergessen, eine veraltete Rückfalloption zu entfernen.

Das könnte aber fatale Folgen haben, denn wenn jemand seit Jahren sein HOME-Verzeichnis dank separater Partition – wie ja auch über all empfohlen – immer wieder wiederverwendet hat, wären darin angesammelte Schlüssel dann futsch. Also wenn, dann müsste da eher eine Transformation an den neuen Ort geleistet werden statt einfach nur einen neuen leeren Schlüsselbund unter ~/.local/share/keyrings/ anzulegen. Deshalb ja mein Vorschlag, darüber etwas in den Artikel zu schreiben.

Es ist nicht Aufgabe dieses Artikels, für Sonderfälle veraltetes Verhalten zu beschreiben. Das kann besser als Supportanfrage im zuständigen Forum diskutiert werden.

OK, das Zusammenführen mag man noch als Sonderfall betrachten, aber wie man den Inhalt von dem GNOME-Schlüsselbund einsehen / auslesen kann, sollte doch von allgemeinem Interesse sein.

Außerdem scheint mir in dem Artikel ein Fehler zu sein, denn mit seahorse bzw. "Passwörter und Verschlüsselung" werden nicht die Schlüssel aus dem GNOME-Schlüsselbund angezeigt, sondern die aus ~/.gnupg/pubring.gpg.

Bei meinen ersten Versuchen hatte ich auch mal ~/.local/share/keyrings umbenannt und durch einen Symlink nach ~/.gnome2/keyrings ersetzt. Dann startete ich signal-desktop und das scheiterte. Sodann habe ich dann ein diff zwischen ~/.local/share/keyrings/user.keystore und ~/.gnome2/keyrings/user.keystore gemacht. Obwohl die Dateien beide 207 Bytes groß sind, zeigte sich, dass sie verschieden sind.

Daraus schloss ich dann, dass das Format der Schlüsseldateien aus ~/.local/share/keyrings nicht kompatibel zu denen aus ~/.gnome2/keyrings ist, und deshalb eine Umkonvertierung vorgenommen werden müsste, wovon ich aber nicht weiß, wie das gehen könnte.

Jetzt fiel mir aber ein, dass ich mich danach erstmal hätte aus- und wieder einloggen müssen um die Funktion zu testen. Deshalb habe ich noch mal einen Test mit einem jungfräulichen HOME gemacht, worein ich vor dem erstmaligen Login nur die Dateien aus /etc/skel/ kopiert hatte. Nach dem Login wurde dann ein neuer leerer Schlüsselbund in ~/.local/share/keyrings automatisch angelegt. Ein Kopieren von ~/.gnome2/keyrings aus dem alten HOME nützt dann nichts, da ~/.local/share/keyrings priorisiert wird. So habe ich dann mal nur die Dateien aus dem alten ~/.gnome2/keyrings/ nach ~/.local/share/keyrings/ kopiert und mich wieder neu eingeloggt. Und siehe da, damit funktionierte dann auch signal-desktop anstandslos. Die Dateien scheinen also doch miteinander kompatibel zu sein.

Dann habe ich nochmal ein jungfäuliches HOME angelegt, und vor dem ersten Einloggen auch noch ~/.gnome2/keyrings vom alten HOME reinkopiert. Nach dem ersten Login wurde dann kein neues ~/.local/share/keyrings mehr angelegt, und signal-desktop funktionierte auch hier auf Anhieb.
Das ist genau die Situation, die man hat, wenn man ein altes HOME-Verzeichnis auf einer eigenen Partition hat und es nach Neuinstallation von Ubuntu immer wieder weiter verwendet. Das hatte ich über 10 Jahre immer so gemacht, und alle Anwendungen und Einstellungen funktionierten dann auf Anhieb. Erst der Neuaufbau eines HOME mit der Übernahme von alten Dateien aus dem alten HOME brachte die beschriebenen Probleme.
Ich denke, diesen Umstand sollte man im Artikel erwähnen, denn das kann jedem passieren, der länger die empfohlene Konfiguration mit separater HOME-Partition verwendet hat.

BTW: Zum Kopieren der Dateien aus /etc/skel/ hatte ich zunächst folgenden Befehl verwendet:

cp /etc/skel/* /home/neuer_user/ 

Dies hatte aber nur die Datei examples.desktop kopiert, aber nicht die .-Dateien. So musste ich dann noch folgendes nachlegen:

cp /etc/skel/.* /home/neuer_user/ 

Wie sieht denn da die passende Wildcard-Syntax aus, die das in einem Rutsch macht?
Und wenn man mittels der Option -r so auch ganze Verzeichnisse rekursiv kopiert, kriegt man eine üble Überraschung, denn dann wird mit ABC/.* auch noch alles von ABC/../XYZ kopiert. Deshalb wüsste ich dafür erst recht gerne die geeignete Wildcard-Syntax.

UlfZibis schrieb:

Außerdem scheint mir in dem Artikel ein Fehler zu sein, denn mit seahorse bzw. "Passwörter und Verschlüsselung" werden nicht die Schlüssel aus dem GNOME-Schlüsselbund angezeigt, sondern die aus ~/.gnupg/pubring.gpg.

Mit Seahorse kann man sowohl den Gnome-Keyring wie auch die GnuPG-Schlüssel und sogar noch weitere Schlüsselsammlungen einsehen und bearbeiten. Man muss nur den Schlüsselbund auswählen. Steht bereits im zuständigen Artikel.

kB schrieb:

Mit Seahorse kann man sowohl den Gnome-Keyring wie auch die GnuPG-Schlüssel und sogar noch weitere Schlüsselsammlungen einsehen und bearbeiten. Man muss nur den Schlüsselbund auswählen. Steht bereits im zuständigen Artikel.

Stimmt, da hast Du recht. Beim ersten Aufruf wird erstmal nur die Unterabteilung GnuPG gezeigt. Erst mit "zurück" sieht man die anderen Sammlungen. Allerdings kann ich auch in denen meine GNOME-Schlüssel nicht finden. Alles, was ich finde, sind genau die Schlüssel, die auch schon mit gpg --list-keys aufgelistet werden. Vor allem finde ich da keinen Schlüssel für die Signal-Datenbank, der ja irgendwie im GNOME-Schlüsselbund drin sein muss, damit Signal Desktop überhaupt funktioniert. Die jungfräuliche Datei ~/.local/share/keyrings/login.keyring hat bei mir 1,2 kB, die alte ~/.gnome2/keyrings/login.keyring aber 17,8 kB. Also irgendwas, unter anderem der Signal-Schlüssel, muss da drin sein, doch kann ich den bisher auf keine Weise auslesen. Der Verweis auf Seahorse im Artikel leistet das nicht.

Mein vorläufiges Fazit für den Artikel:

1. Wenn vorhanden, wird der alte Ort des GNOME-Schlüsselbunds – ~/.gnome2/keyrings/ – auch in aktuellen Installationen von Ubuntu weiterverwendet.

2. Ist gleichzeitig auch der neue Ort ~/.local/share/keyrings/ vorhanden, wird nur dieser verwendet, und ersterer ignoriert.

3. Um auf den neuen Stand umzurüsten, kann man die Dateien von ~/.gnome2/keyrings/ nach ~/.local/share/keyrings/ kopieren / verschieben, und sollte dabei keine Anwendungen, die diese verwenden könnten, geöffnet haben. Es ist darauf zu achten, dass die Zugriffsrechte des Ordners auf drwx------ eingestellt sind, die der darin befindlichen Dateien auf -rw------- und der Besitzer von allen immer $USER ist. Danach muss man sich sofort aus dem Desktop abmelden und sich wieder neu anmelden.
   Schon in ~/.local/share/keyrings/ vorhandene neuere Schlüssel werden dabei allerdings gelöscht. Wie ein Zusammenführen bewerkstelligt werden könnte, ist bisher unbekannt.

4. Weiterhin ist bisher unbekannt, wie man die Schlüssel im GNOME-Schlüsselbund einsehen / auslesen kann.

Dies alles habe ich aktuell unter Ubuntu 22.04 so festgestellt.