staging.inyokaproject.org

DJKUhpisse schrieb:

Ich habe das Problem gelöst, indem ich den Key mit gpg verarbeitet habe und dann eine .gpg in trusted.gpg.d gelegt habe. Dann meckert der nicht mehr. Kann ich gerne raussuchen.

Ich hab' das jetzt mal mit einem Schlüssel probiert, ihn also von /etc/apt/keyrings/ nach /etc/apt/trusted.gpg.d/ verschoben. Dabei kommt dann folgendes bei raus:

sudo apt update
[.....]
W: Während der Überprüfung der Signatur trat ein Fehler auf. Das Depot wurde nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-Fehler: https://packagecloud.io/judd/jpilot/ubuntu jammy InRelease: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 341679CBB9973707
W: Fehlschlag beim Holen von https://packagecloud.io/judd/jpilot/ubuntu/dists/jammy/InRelease Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 341679CBB9973707

Insofern wundert mich, dass das bei Dir funktioniert hat.

Alternative zu apt-key add, was ja in trusted.gpg speichert und damit angemeckert wird. Ich suche die Variante, die heute seitens Ubuntu/debian gewünscht ist.

DJKUhpisse schrieb:

Alternative zu apt-key add, was ja in trusted.gpg speichert und damit angemeckert wird. Ich suche die Variante, die heute seitens Ubuntu/debian gewünscht ist.

Danke, jetzt wird mir das Missverständnis klar. Ich hatte Dich so verstanden, dass Du schon Alternativen kennst, und "einen Weg suchst, wir man sie (z.B. in einem Artikel) aufzeigt."

Man könnte also z.B. den Leuten vom GNU-coreutils-Projekt vorschlagen, den apt-key-Befehl um eine passende Option zu erweitern, anstatt ihn veralten zu lassen, oder den apt-Befehl um den Unterbefehl add-key erweitern, der sich dann im Gegensatz zu apt-key konform verhält.

EDIT: Ich sehe gerade, dass GNU gar nichts mit APT zu tun hat, also wäre wohl Debian der Ansprechpartner.

Ich hab' hier eine interessante Diskussion dazu gefunden: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968148

Wenn ich es richtig verstehe, geht es um 2 Dinge:

1. /etc/apt/trusted.pgp soll grundsätzlich nicht mehr benutzt werden, sondern statt dessen einzelne Schlüssel in /etc/apt/trusted.pgp.d/. Genau dafür steht die deprecation-Warnung.

2. Schlüssel für fremde Repos sollen aus Sicherheitsgründen nach /etc/apt/keyrings/, bzw. nach /usr/share/keyrings/, wenn das Paket eine eigene Schlüsselverwaltung anbietet, wie z.B. in meinem Fall bei Linux Mint mit linuxmint-keyring. Wenn man es falsch macht, wird bisher keine Warnung ausgegeben. Die dazu nötige Info – sources-list – ist schwer zu finden. Debian scheint der Diskussion oben zufolge die Meinung zu vertreten, dass es keinen Ersatz für apt-key geben soll, sondern die Fremdpaket-Anbieter korrekte Installationsanleitungen bereitstellen sollen.

Aus letzterem ist es deshalb kein Wunder, dass es vielerorts falsch gemacht wird oder zumindest halb-falsch, wie z.B. bei WineHQ, wo die Anleitung /usr/share/keyrings/ vorgibt, obwohl WinHQ gar keine eigene Schlüsselverwaltung hat. Schon peinlich für so ein prominentes Projekt. Dieses Nischen-Projekt macht es z.B. richtig.

Doc_Symbiosis schrieb:

Naja, "managed by package" heisst, dass die Datei aus dem Paket kommt, also auch ggf. überschrieben wird, wenn Du das Paket aktualisierst. Die Datei "managed by admin" wäre dann wohl eher die richtige, um die Einstellungen dauerhaft im System zu haben.

Ich muss meine Meinung hierzu noch mal erweitern. Wenn man den Schlüssel wie ich hier manuell verwaltet, ist /etc/apt/keyrings/ wohl der richtige Ort. Nutzt man aber das DEB-Paket, sollte der Schlüssel nach /usr/share/keyrings/, was damit automatisch passieren sollte.

Schaut man sich dieses DEB-Paket aber mal von innen an, sieht man, dass der Schlüssel doppelt abgelegt wird, also in /etc/apt/trusted.gpg.d/ und /usr/share/keyrings/, was mich wiederum verwirrt. Ja vielleicht sollte man dieses Paket auf Ubuntu eben genau nicht installieren, da Linux-Mint-Pakete für Ubuntu ja quasi fremd sind, sondern die manuelle "Admin"-Verwaltung wählen, also Schlüssel manuell nach /etc/apt/keyrings/. Dieser Tipp ist also mit Vorsicht zu genießen.

Ich denke, man sollte diesen Artikel hier als Referenz ansehen und auch in betreffenden hiesigen Artikeln verlinken: https://wiki.debian.org/DebianRepository/UseThirdParty

Darin ist z.B. zu lesen: "In releases older than Debian 12 and Ubuntu 22.04, /etc/apt/keyrings does not exist by default. It SHOULD be created with permissions 0755 if it is needed and does not already exist."

UlfZibis schrieb:

Schaut man sich dieses DEB-Paket aber mal von innen an, sieht man, dass der Schlüssel doppelt abgelegt wird, also in /etc/apt/trusted.gpg.d/ und /usr/share/keyrings/, was mich wiederum verwirrt.

Korrektur: Die beiden Dateien haben zwar den gleichen Namen, linuxmint-keyring.gpg, sind aber nicht dieselben, da unterschiedlich groß. Vielleicht kann jemand erläutern, was das bedeutet, und ob es sinnvoll ist, dieses Linux-Mint-Paket auf Ubuntu zu verwenden. Leider enthält es nicht die dazugehörige Quelle, linuxmint-vanessa.list, diese müsste also immer noch manuell erstellt werden.

Hallo UlfZibis,

Die Keyrings sind für die Repos von Distributionen (Mint, Ubuntu, Manjaro usw.) Darin sind immer eine Latte von Schlüsseln, die auch mal "aktualisiert" werden müssen ....

Die Anderen / Einzelnen sind nur die "Quellen" aus PPA Projekten.

Gruss Lidux

Lidux schrieb:

Die Keyrings sind für die Repos von Distributionen (Mint, Ubuntu, Manjaro usw.) Darin sind immer eine Latte von Schlüsseln, die auch mal "aktualisiert" werden müssen ....

Ich denke mal, das gehört eher zum anderen Thema. Deshalb habe ich dort drauf geantwortet.