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

# zypper se -s openvpn   # mit rpm im lokalen repo
v  | openvpn                            | Paket      | 2.6.14-2.4   | x86_64 | update
v  | openvpn                            | Paket      | 2.6.14-2.3   | x86_64 | update
i+ | openvpn                            | Paket      | 2.6.19-325.5 | x86_64 | repo_rk
v  | openvpn                            | Paket      | 2.6.14-2.4   | x86_64 | base-oss

# zypper se -s openvpn   # ohne rpm im lokalen repo
i+ | openvpn                            | Paket      | 2.6.19-325.5 | x86_64 | (Systempakete)
v  | openvpn                            | Paket      | 2.6.14-2.4   | x86_64 | update
v  | openvpn                            | Paket      | 2.6.14-2.3   | x86_64 | update
v  | openvpn                            | Paket      | 2.6.14-2.4   | x86_64 | base-oss

# zypper ve    # ohne rpm im lokalen repo
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Die Abhängigkeiten aller installierten Pakete sind berücksichtigt.

zypper meckert bei Abwesenheit des rpm-Files jedenfalls nicht wegen Abhängigkeiten ...

Zitat von Sauerland

Murks.

Gebaut wird als User im Users /home, nur installiert wird als root.

Daher ist es egal, wo die rpms liegen, nur root kann installieren.

Wenn ich ein lokales Verzeichnis als Repo definiere und mir ein böser Mensch dort ein manipuliertes rpm hereinschiebt - was mag dann wohl passieren, wenn root das nächste Mal "zypper (d)up" ausführt ?

Zitat von Sauerland

Ich weiß auch nicht, wie slowroll jetzt mit den Dateirechten im /home eines Users umgeht, bei einer Neuinstallation von Leap 16.0 wird Username/Username benutzt.

Ich bin da altmodisch: zypper dup läuft mit root-Rechten und soll dann auch nur RPMs anfassen bzw. einspielen, die root gehören - und nicht Files aus irgendwelchen User-Verzeichnissen ...

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

Ü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/

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.