Beiträge von dagny

    Der Signing key wird automatisch ausgegeben:

    https://news.opensuse.org/2023…new-4096-bit-signing-key/

    Danke Sauerland,

    in Deinem Link wird darauf hingewiesen, dass die aktuellen Schlüssel für Tumbleweed wohl auch aus dem RPM-Paket "openSUSE-build-key" stammen.

    "... If you are regulary updating your Tumbleweed installation, the key will already be imported to the RPM keyring, and also in the openSUSE-build-key package. ..."

    Das hat bei mir auch wunderbar geklappt, der aktuelle Schlüssel "29b700a4" war bei mir bereits im Post #53 integriert.

    Nochmals danke :)

    Erst mal vielen Dank, Euch allen zur Mithilfe bei der Fehlereingrenzung.


    Die Warnung "... (NOKEY) ..." von den Paketen meines packman-Repo ist bei einem kürzlich durchgeführten "zypper dup" nicht mehr erschienen.

    Code: zypper dup # kleiner Auszug
    Abrufen: chromium-ffmpeg-extra-103.0.5060.114-1.12.x86_64 (packman)                                                                                                       (1/42),   1,1 MiB    
    Abrufen: chromium-ffmpeg-extra-103.0.5060.114-1.12.x86_64.rpm ...........................................................................................................[fertig (512,0 KiB/s)]
    .
    .
    .
    Überprüfung auf Dateikonflikte läuft: .................................................................................................................................................[fertig]
    ( 1/42) Installieren: chromium-ffmpeg-extra-103.0.5060.114-1.12.x86_64 ..................................................................................[fertig]

    zypper_dup_20230122_gesamt.txt


    Mögliche Lösungen zu dem Problem (NOKEY) hatte wohl einer der beiden Posts gebracht:

    Post #46 (Weshalb allerdings das Löschen und das Neuinstallieren ein und desselben keys helfen kann, ist mir ein Rätsel.)

    Post #56


    Eingangsfrage:

    Um das Ganze noch zum Abschluss zu bringen, möchte ich nochmals kurz auf meine Eingangsfragen von Post #1 zurückkommen.

    1. Frage) Wie erhalte ich den aktuellen Schlüssel, wenn der alte ausgelaufen ist bzw. kurz vor seinem Ablaufdatum steht?

    2. Frage) Muss ich mich immer "händisch" um den aktuellen Schlüssel kümmern oder kann man das einfacher haben?

    Für openSUSE:

    Ich habe gesehen, dass das Paket "openSUSE-build-key" bei mir installiert ist.

    Dieses Paket kümmert sich wohl um die aktuellen Schlüssel für die Pakete von openSUSE.


    Für Packmann:

    Ebenso gibt es bei "packman" ein Paket "rpmkey-packman - The packman rpm public keys", das bei mir noch nicht installiert ist.

    Übernimmt dieses Paket die Schlüsselverwaltung für die Packman-Pakete?

    Wenn das so wäre, sollte man es vermutlich auch installieren - Oder?


    Für Vivaldi:

    Bei zwei anderen Rechnern von mir wurde der neue Vivaldi problemlos und ohne "händische" Nachinstallation der neuen Schlüssel upgegradet.

    Sowohl bei einem KUbuntu 18.04 (mir ist bekannt, dass es sich hier um eine andere Paketverwaltung handelt) als auch bei einem zweiten Tumpleweed-Rechner von mir.

    Irgendwie habe ich bei meinem zweiten Tumpleweed-Rechner den aktuellen Vivaldi-Key "Vivaldi Package Composer KEY08 <packager@vivaldi.com>" automatisch erhalten. Und so kannte ich das auch in der Vergangenheit.

    Vom Vivaldi-Repo ist bei mir nur das Paket "vivaldi-stable - Vivaldi" installiert. Vermutlich kümmert sich Vivaldi selbst um seinen aktuellen Schlüssel (was bei meinem fehlerhaften Tumpleweed-Rechner scheinbar einfach einmal nicht geklappt hat).


    Sollte jemand noch Hinweise zu meinen beiden Fragen haben wäre ich dafür dankbar.

    Ansonsten werde ich das Thema bald schließen.


    Vielen Danke für Eure Mithilfe.

    Wir kommen jetzt mal wieder runter und wenden uns dem Thema zu. Aggressionen aufzubauen ist nicht zielführend. Das es für ein Repo von einem Ersteller jetzt zwei Schlüssel geben soll, wäre mir neu. Ich habe mich mit dem Thema aber noch nicht weiter befasst. Ich achte immer nur darauf, das meine Schlüssel und meine Repos nicht doppelt und aktuell sind. Das kann aber jeder machen, wie er will.

    "Wir kommen jetzt mal wieder runter und wenden uns dem Thema zu. Aggressionen aufzubauen ist nicht zielführend. ..."

    Wohl wahr :)


    " ... Ich achte immer nur darauf, das meine Schlüssel und meine Repos nicht doppelt und aktuell sind. ..."

    So wie ich das sehe, kann ich den gleichen Schlüssel gar nicht in die Repo einfügen. Dann erscheint bei mir eine Fehlermeldung, wenn ein Schlüssel bereits in der Repo existiert.

    Wenn ich abgelaufene Schlüssel in der Repo finde, entferne ich die in der Regel auch. Natürlich schaue ich da nicht ständig rein und es kann sich schon mal sein, dass der ein oder andere Schlüssel darin beteits abgelaufen ist.


    Jetzt warte ich mal auf das nächste zypper dup mit dem Software von meinem Repo "packman" upgegradet wird. Vielleicht sind die die Warnmeldung bereits weg.


    Danke

    Ja klar ... mache ich auch immer so. Ich trage auch immer zwei gleiche Schlüssel am Schlüsselbund für jedes Schloß mit mir herum. Macht ja nix, die funktionieren ja beide. Mein Schlüsselbund wird größer und unübersichtlicher, aber das ist ja egal.

    :D :D :D :D

    Und, wenn du beide packman Schlüssel gelöscht hättest, wie Alero im Post 47 empfohlen hatte, wären die nicht beide in Post 53 von Sauerlands Abfrage zu sehen gewesen. Allerhöchstens hätte man da einen gesehen. Du veralberst hier die Leute, oder? :/

    Hallo Peppino,

    na klar, ich schreibe das hier nur "um die Leute zu veralbern".

    Hast Du eigentlich schon einmal gelesen, was Du selbst geschrieben hast?

    Und vor allem hast Du zu diesem Thema schon einen einzigen vernünftigen Beitrag geschrieben?


    Es handelt sich um zwei Schlüssel, die bei beiden Quellen gleich sind. Die beiden Schlüssel sind aber absolut unterschiedlich und machen auch bei Weitem nicht das Gleiche.

    Ja, ich habe nicht alle Empfehlungen gleichzeitig oder sofort eingegeben, da ich einen Fehler eingrenzen möchte und nicht erraten!


    Wenn Du nichts Vernünftiges beizutragen hast, spare Dir einfach das Posten hier. X(

    Ja, das wäre meine nächste Frage gewesen, warum zweimal packman (hatte ich dir nicht weiter oben empfohlen, die Schlüssel von packman zu löschen?) ... und nun die Frage .. warum zwei mal Vivaldi? Was machst du da? :smilie_pc_057:

    "... warum zweimal packman ..."

    Beide Packman Schlüssel gibt es u.a. hier: https://ftp.fau.de/packman/

    und auch auf Deinem empfohlenen Link: http://ftp.gwdg.de/pub/linux/misc/packman/

    Die Schlüssel der beiden Quellen sind identisch.

    Ja, das wäre meine nächste Frage gewesen, warum zweimal packman (hatte ich dir nicht weiter oben empfohlen, die Schlüssel von packman zu löschen?) ... und nun die Frage .. warum zwei mal Vivaldi? Was machst du da? :smilie_pc_057:

    "... (hatte ich dir nicht weiter oben empfohlen, die Schlüssel von packman zu löschen?) ..."

    Hab ich ja gemacht! siehe Post #56

    Ja, das wäre meine nächste Frage gewesen, warum zweimal packman (hatte ich dir nicht weiter oben empfohlen, die Schlüssel von packman zu löschen?) ... und nun die Frage .. warum zwei mal Vivaldi? Was machst du da? :smilie_pc_057:

    Das ist ganz einfach und wurde nicht von mir erfunden!

    Die GPG-Keys von Vivaldi haben eine Laufzeit, wie es bei Keys eigentlich üblich sein sollte.

    Mit dem "KEY07" wurden die älteren Vivaldi-Versionen signiert,

    mit dem neuen "KEY08" wird der Vivaldi ab Version "5.6.2867.58 (Stable channel) stable (64-Bit)" signiert.


    Für die Installation des aktuellen Vivalti habe ich einfach den neuen Key eingebunden, da damit auch die neue Version signiert ist!

    Den ältern Key könnte ich natürlich löschen, was ich auch irgendwann machen werde, wenn er abgelaufen ist.

    Er hat aber noch eine Gültigkeit bis 25.02.2023 und schadet ja auch nicht.

    Da ist aber Packman 2 mal vorhanden.....

    Lösche beide und als root:

    Code
    zypper clean -a
    Code
    zypper ref

    Da sollte dann eine Abfrage nach dem key erfolgen.

    Ja ich weiß, diesen Schlüssel:

    Code: # PackMan Build Service (PackMan Build Service)
    Schlüssel: F899F20D9A795806
    Name: PackMan Build Service (PackMan Build Service) <packman@links2linux.de>
    Fingerabdruck: 2A6BAA690B3019CE45B3302DF899F20D9A795806
    Erstellt: 10.08.2007
    Der Schlüssel läuft nie ab.

    hatte ich in der Fehlersuche erst hinterher mit aufgenommen. Hat aber auch nichts gebracht.


    Hab die beiden Schlüssel gelöscht und Deine Befehle ausgeführt. Bei der Abfrage:

    habe ich "immer vertrauen" gewählt.

    Jetzt sehen die Schlüssel wieder wie folgt aus:

    Code: # rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'
    gpg-pubkey-3dbdc284-53674dd4    gpg(openSUSE Project Signing Key <opensuse@opensuse.org>)
    gpg-pubkey-ee3d166a-5fe932a4    security OBS Project <security@build.opensuse.org> public key
    gpg-pubkey-39db7c82-5f68629b    SuSE Package Signing Key <build@suse.de> public key
    gpg-pubkey-c27aa466-5ff5836d    Vivaldi Package Composer KEY07 <packager@vivaldi.com> public key
    gpg-pubkey-29b700a4-62b07e22    openSUSE Project Signing Key <opensuse@opensuse.org> public key
    gpg-pubkey-4218647e-61f7b089    Vivaldi Package Composer KEY08 <packager@vivaldi.com> public key
    gpg-pubkey-1abd1afb-450ef738    PackMan Project (signing key) <packman@links2linux.de> public key

    OK, Spiegel sind immer so eine Sache für sich ...



    Das würde mich schon gewaltig stören. Ich lade mir sichere Software von einem unsicheren Server. Aber jeder, wie er möchte.

    Ok, da ist was dran. :smilie_school_012:


    Das ist bei mir schon einige Zeit her und da bei der Listung unter http://packman.links2linux.de/mirrors der Spiegelserver mit "http://..." angegeben ist, hatte ich das damals auch einfach so übernommen.


    Habs nach https://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/ geändert.

    Danke für Deinen Hinweis.


    Ich dachte/denke, die Signaturprüfung mit dem GPG-Key gewährleistet die Konsistenz der Pakete.

    Die "openSUSE-Tumbleweed"-Repos stehen auch nur mit "http://..." in den Software Repositories. :/