Beiträge von rkbwde

  • librpm.so.8 fehlt - unwissentlich gelöscht

    Zitat von luigi

    ... zypper lässt sich aber nicht, siehe post #11.

    Postet mal

    Code
    which zypper
ldd /usr/bin/zypper

    Wenn da wirklich eine lib fehlt, muss man sie von einem anderen System herüber kopieren oder kann versuchen, einen symlink auf eine vorhandene mit anderer (am besten neuerer) Version zu setzen.


    Wenn zumindest rpm funktioniert, könnte es helfen, die Installationspackages von zypper manuell herunterzuladen und mit rpm manuell einzuspielen.


    Es bleibt aber eine heikle Kiste ohne Erfolgsgarantie ....

  • librpm.so.8 fehlt - unwissentlich gelöscht

    Nur so eine Idee: Wenn sich rpm und zypper starten lassen, scheinen ja die benötigten libs vorhanden zu sein. Dann könnte man mit einem dummy-Package die Dependency zu librpm.8 "befriedigen", damit das Upgrade erstmal durchläuft, und danach in Ruhe aufräumen (z.B. mit "zypper ve" schauen, wo es noch klemmt) ... :/

  • zypper hält Package für veraltet trotz höherer Versionsnr. ?

    Um zur ursprünglichen Frage zurückzukommen, fasse ich zusammen:


    "zypper dup" behandelt alle Packages, die nicht in einem seiner Repos sind, als "alt" oder "überflüssig", d.h. es spielt ältere Versionen wieder ein oder löscht die Packages gänzlich.


    Als Workaound helfen Package Locks auf die eigenen Packages oder ein lokales Verzeichnis als Repo hinzufügen, indem die eigenen Packages liegen.

  • zypper hält Package für veraltet trotz höherer Versionsnr. ?

    Zitat von Alero

    Wieso? Hast du die Source überprüft? Hast du das Programm Zeile für Zeile überprüft?

    Natürlich lese ich die Original-Source nicht komplett. Aber bei den home-Repos prüfe ich zumindest, ob der Hash-Wert mit dem der Original-Source von openvpn.net übereinstimmt - gerade weil VPN sicherheitskritisch ist. Deshalb binde ich die Home-Repos auch nicht dauerhaft ein, sondern baue selber.


    Mir geht es im wesentlichen um die Distro-spezifischen Patches, z.B. unterschiedliche Pfade zu den config-Files. Sonst würde ich direkt aus der Original-Source bauen ...

  • zypper hält Package für veraltet trotz höherer Versionsnr. ?

    Es ist ein altes Prinzip, dass root nicht ungeprüft mit User-Files arbeiten sollte, die dann erhöhte Rechte erhalten. Daher dürfen auch im PATH für root keine user-writable Directories enthalten sein, um zu verhindern, dass root unsichere Kommandos untergeschoben werden können.


    Kompromittierung lässt sich natürlich nie ganz verhindern. Aber es ist sicherheitstechnisch schon ein Unterschied, ob ich ein Binary-RPM ungeprüft von irgendwo her ziehe oder das Package aus der Source selbst baue.


    I.d.R. enthält so ein Source-RPM die Original-Source als tar-Archive (lässt sich in meinem Fall gegen die Original-Sourcen von openvpn.net checken) und einige Patches, die meistens überschaubar sind.


    Aber sei es drum, da verfolgen wir unterschiedliche Ansätze.

  • zypper hält Package für veraltet trotz höherer Versionsnr. ?

    Zitat von Sauerland

    Da kannst du die Rechte ja einschränken, siehe z.B. das .ssh Verzeichnis in deinem /home.......


    Noch mal:

    Ist Murks.

    Ich sehe das anders: Bei Deinem Ansatz reicht es, einen User zu kompromittieren, bei meinem muss schon root kompromittiert werden - was in letzter Zeit dank copy.fail & Co. aber auch nicht so schwer war :saint:


    Übrigens gibt es eine spannende Lektüre zu der (zum Glück in letzter Minute aufgedeckten) Kompromittierung von ssh via xz: https://noise.getoto.net/2026/…-book-on-the-xz-backdoor/

  • zypper hält Package für veraltet trotz höherer Versionsnr. ?

    Zitat von Sauerland

    Du meinst also, du löscht (verschiebst) das Paket aus dem Verzeichnis?



    Dann wird eine Abhängigkeit nicht funktionieren........

    Ja, genau - ich schiebe das rpm-File aus dem lokalen Repo-Verzeichnis heraus.


    Das dürfte aber an den Abhängigkeiten nichts verändern; die waren davor erfüllt und bleiben es auch, wenn ich das bereits installierte RPM aus dem Repo schiebe ...


    Es ändert sich nur der Paketstatus wieder zu Systempaket X/