staging.inyokaproject.org

UlfZibis schrieb:

Dafür sind wir ja Linux-Nutzer, weil wir wissen, wo man bei WinzigWeich dran ist.

Ach hör doch auf mit dem MS-Bashing!

Was gibt es denn zu schimpfen, wenn Microsoft es nur seinen Produktnutzern so bequem und geschmeidig wie möglich machen will?

Wer immer das postinst Script ausgetüftelt und geschrieben hat verdient ganz im Gegenteil Applaus! Das postinst Script führt vor wie die Sicherheitschlüssel mit Leichtigkeit ausgehebelt werden. Bei Bedarf kann ein beliebiger Schlüssel an beliebige Stelle gesetzt werden und der dazu passende Pfad beim "signed-by=" in der Source List gleich mit dazu. Es bietet also überhaupt gar keinen Vorteil einen Schlüssel nach /etc/apt/keyrings/ zu installieren. Schon mal gar nicht, wenn die "signed-by=" Schlüssel sonst unter /usr/share/keyrings/ liegen, wo man dann wenigstens in einem Verzeichnis den Überblick behalten könnte.

Ich finde es eher übersichtlich, wenn Quellen und Schlüssel im gleichen Zweig, also /etc/apt/... zu Hause sind. /usr/share/keyrings sehe ich eher als Ausnahme für selten vorkommende paket-verwaltete Schlüssel.
Und auch diese scheinen für den Wurzel-Schlüssel /etc/apt/ zu benötigen, siehe Verzeichnis von data.tar.xz in http://packages.linuxmint.com/pool/main/l/linuxmint-keyring –> linuxmint-keyring_2022.06.21_all.deb

UlfZibis schrieb:

/usr/share/keyrings sehe ich eher als Ausnahme für selten vorkommende paket-verwaltete Schlüssel.

Nein. Das signed-by=/usr/share/keyrings/ soll der neue Standard werden, zusammen mit der Pflichtangabe signed-by, bzw. später dann, mit Ubuntu Version 24.04, wenn die Verwaltungswerkzeuge das DEB822-Format können, dann "Signed-By: /usr/share/keyrings/", siehe nochmals:

• https://discourse.ubuntu.com/t/spec-apt-deb822-sources-by-default/29333

trollsportverein schrieb:

Nein. Das signed-by=/usr/share/keyrings/ soll der neue Standard werden,

Ja, aber nur für paket-verwaltete Schlüssel. Wir sprechen hier aber über manuell verwaltete und Fremdschlüssel.

• https://discourse.ubuntu.com/t/spec-apt-deb822-sources-by-default/29333

Schlechtes Beispiel, denn da geht es überhaupt nicht um Fremdschlüssel, sondern um Ubuntus ureigene Distro-Schlüssel.

Nun ja, ich kann ja auch einfach mal abwarten wie sich das weiter entwickelt. Denn so, wie es nun vermurkst ist, kann noch nicht mal die Installation vom WineHQ funktionieren. Auf meinem System ist es wie zuvor auch in einem funktionierendem Zustand. So vermurksen, dass es nicht mehr funktioniert, lässt sich wohl auf Verwirrung stiften beim WineHQ zurückführen. Sowohl bei Debian als auch bei Ubuntu wurde der Schlüssel zuvor unter /usr/share/keyrings/ platziert. Das lässt sich in der Änderungshistorie dort im Wiki nachschauen.

Ich muss hier doch noch mal ran.

Ferdinand Thommes, sagt der Name den hiesigen Foristen etwas? Schaut mal bitte auf Linuxnews:

• Debian 11: Repositories aus 3. Hand ohne apt-key einbinden

Dort ist es auch für die Drittanbieter Repositories "signed-by=/usr/share/keyrings/".

Hi Trollsportler,

ich bin ja fasziniert, wie Du in der Sache tiefbohrst. Bin ja auch so'n Typ. Für die Sicherheit des Systems ist es letztlich egal, wo ein Fremdschlüssel abgelegt wird, nur /etc/apt/trusted.pgp bzw. ../trusted.pgp.d/ sind tabu.

trollsportverein schrieb:

Ferdinand Thommes, sagt der Name den hiesigen Foristen etwas? Schaut mal bitte auf Linuxnews:

• Debian 11: Repositories aus 3. Hand ohne apt-key einbinden

Dort ist es auch für die Drittanbieter Repositories "signed-by=/usr/share/keyrings/".

Der Artikel ist von 2021. Zu dieser Zeit war der Pfad /etc/apt/keyrings/ noch nicht automatischer Bestandteil des Systems, man hätte ihn manuell erstellen müssen. Das ist wohl der Grund, warum viele dann /usr/share/keyrings/ gewählt haben. Ich weiß leider auch nicht, seit wann die Debian-Vorgabe bzgl. /etc/apt/keyrings/ existiert. Vielleicht ist die ja auch noch nicht so alt ... oder wurde eben von vielen übersehen, weil sie leider auch sehr versteckt und unauffällig in der langen Debian-Anleitung untergebracht ist. Für mich macht es jedenfalls Sinn, alles manuell gebastelte nah beieinander zu haben:

• /etc/apt/keyrings/

• /etc/apt/sources.d/

• /etc/apt/preferences.d/

/etc/... ist nun mal der Ort für Einstellungen und Konfigurationen, systemvorgegebene und persönliche. /usr/... ist der Ort für vom systemerweiternde Pakete. Deshalb in letzterem nur in Pakete eingebundene Schlüssel.

/usr/ sind die Unix System Resources.

• https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html

Edit: hier gibt es auch ein Script für die Migraton der Schlüssel.

• https://gist.github.com/maxhq/7dadf55064aaadc4d9e5993f89fad7b0

Ich hab es aber nicht ausprobiert, habe meine Reposotry Sammlung längst mit nano gewartet.

Warum in die Ferne schweifen, wenn das Gute liegt so nah?

• Verzeichnisstruktur

Das Ding könnte auch sein, das viele nur Linux kennen. Die alte Herkunft des /usr/ Verzeichnis daher nicht ganz so bekannt sein könnte. Man kann sich ja mal FreeBSD anschauen, da gibt es das eigentliche Betriebssstem, das FreeBSD. Das ist mehr als nur ein Kernel wie bei Linux. Daher befinden sich globale Einstellungen von Drittsoftware auch in /usr/, so gibt es zum Beispiel auf FreeBSD auch ein Verzeichnis /usr/local/etc/ in dem dann in einem Unterverzeichnis wiederum die Einstellungen für die Ports zu finden sind. Ports sind die auf FreeBSD portierten Anwendungen. Auf die Unterschiede zwischen Ports und Fertigpakete eingehen würde hier an der Stelle zu weit gehen. Um aber auf /usr/ zurückzukommen, die Schlüssel für die Pakete "pkg" der Drittsoftware werden dort auch konfiguriert, hier mal ein Beispiel einer /usr/local/etc/pkg/repos/FreeBSD.conf für die Schlüssel:

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

UlfZibis schrieb:

... Ich weiß leider auch nicht, seit wann die Debian-Vorgabe bzgl. /etc/apt/keyrings/ existiert. Vielleicht ist die ja auch noch nicht so alt ...

Jetzt weiß ich es. Die Änderung war am 23. Mai 2022, siehe Hinweis in: https://bugs.winehq.org/show_bug.cgi?id=53554#c0 Da ist auch sehr schön erläutert, warum das so gemacht wurde.

Es steht tatsächlich in der alten Manpage von Februar 2022. Dann hat man vier Verzeichnisse wo irgendwelche Schlussel herumliegen können. Super! Das ist der Weg! Der Weg maximale Unübersichtlichkeit zu erzeugen. Von mir aus alles nach /etc/apt/keyrings/ mit Pfadangabe durch "signed-by=" bzw. wenn die Tools so weit sind, dann im DEB822-Format "Signed-By:, aber Schlüssel auf 4 Verzeichnisse verstreuen? Was soll der Blödsinn? Wovon dann auch noch in zwei Verzeichnissen die Schlüssel hochgefährlich sind, da sie jedes Paket ohne Schlüsselpfadangabe nutzen kann? *Kopfschüttel* Ich schau mir bald mal Kinetic Kudu an, ist ja bald Release. Aber trotz aller Bequemlichkeit auf dem ansonsten geschätzten Kubuntu ist das nun der Auslöser, der mich an Debian und Ubuntu zweifeln lässt.

Es gibt die Option, den Schlüssel direkt mit gpg zu laden ohne wget zu nutzen:

gpg --fetch-keys 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0xc77205f7194a3e1abe2df9a4b7b9c16f2667ca5c'

Kennt wer eine Option, diese dann direkt in eine Datei auszugeben statt in einen Schlüsselbund zu importieren?

EDIT: Wir sollten noch den Fall reinbringen, dass nur der Fingerprint bekannt ist wie bei den ganzen apt-Meldungen. Ich versuche da mal was rauszufinden.

DJKUhpisse schrieb:

Es gibt die Option, den Schlüssel direkt mit gpg zu laden ohne wget zu nutzen:

gpg --fetch-keys 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0xc77205f7194a3e1abe2df9a4b7b9c16f2667ca5c'

Kennt wer eine Option, diese dann direkt in eine Datei auszugeben statt in einen Schlüsselbund zu importieren?

Vielleicht so:

sudo -H gpg --fetch-keys 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0xc77205f7194a3e1abe2df9a4b7b9c16f2667ca5c' -o /etc/apt/keyrings/my-dream-key.gpg 

Wichtig ist in dem Zusammenhang immer, dass sudo mit -H aufgerufen wird, und dass das Verzeichnis /root/.gnupg vorhanden ist und über die richtigen Rechte verfügt.

Wir sollten noch den Fall reinbringen, dass nur der Fingerprint bekannt ist wie bei den ganzen apt-Meldungen. Ich versuche da mal was rauszufinden.

Das geht ungefähr so (lässt sich vermutlich vereinfachen): 9324890

gpg --no-default-keyring --keyring /etc/apt/keyrings/linux-mint-archive.gpg --keyserver keyserver.ubuntu.com --recv-keys A6616109451BBBF2

Sollte dann nicht --keyring auch bei einer normalen URL funktionieren?