OK, ich habe eine Liste von CVEs erhalten, die ich für meine Systeme fixen soll.
Leider stellte sich heraus, dass es dafür noch keine Patches (SLES15 SP7) gibt.
(OpenSSH, ClamAV, Kernel)
Also habe ich jeweils einen Support Case mit der Priorität “hoch” erstellt (wir haben einen “24x7” Vertrag). Beim Zweiten kam die Meinung, dass das nicht “Prio hoch” sei gemäß https://www.suse.com/support/handbook/severity-types/.
Beim dritten Case wurde dieser als angeblicher Duplicate (ohne Nennung der Nummer!) geschlossen, ohne dass ich reagieren konnte.
Für jemand bei SUSE, der da reinschauen kann: #02018685 (Linux kernel vulnerabilities with no patches yet).
Was mich vor allem stört: Auf der SCC Support Seite fehlt mit der Kontakt zum “Support Delivery Manager”, dem man Probleme mit dem Support melden kann. Leider ist so etwas in letzter Zeit wohl nötig.
Zu Zeiten der Cyberangriffe ist das leider ein Thema, mit dem man sich beschäftigen muss.
Es könnte sein, dass die CVEs nicht auf den konkreten SUSE Kernel zutreffen, aber so kann man doch keinen professionellen Support betreiben!
Wenn du etwas sauer bist ist das gut, aber wir sind daran nicht schuld.
Also du solltest besser wissen wo deine SLES Kontakte sind als wir, Weil wir die nicht benutzen und du anscheinend SLES angeschaft hast mitsamt einige Unterstützung.
Und du kannst uns ruhig unsere Linux openSUSE Probleme überlassen. Dagegen wissen wir nicht wie deine SLES Unterstützung laufen soll oder was deine Rechte (wofür du anscheinend gezahlt hast) sind und wo die zu holen.
Bevor man sich mit dem hundslausigen und sauteuren Hotline-Support von SUSE herumschlägt, wäre bei bekannten Sicherheitslücken das Konsultieren dieser SUSE-Webseite: https://www.suse.com/security/cve/index.html
angebracht.
Puha, ich weiß gerade nicht, was mich hier mehr “vor allem stört”, sich auf dem offenen Forum der freien Variante zu beschweren, statt den zuständigen, kostenpflichtigen Support zu kontaktieren oder solche Kommentare. Der Link war ja immerhin wohl passend, aber ich denke, das kann hier bald mal geschlossen werden.
Und du kannst uns ruhig unsere Linux openSUSE Probleme überlassen.
Wenn im Linux-Kernel von SLES eine bekannte Sicherheitslücke drin ist und SUSE diese Sicherheitslücke nicht schliesst, dann betrifft dies auch OpenSUSE Leap-Nutzer:innen, wenn Sie den offiziellen Linux-Kernel aus den offiziellen Leap-Paketdepots (Repositories) verwenden.
Schliesslich wird für OpenSUSE Leap ein grosser Teil an Software 1:1 von SUSE übernommen.
Was mich am meisten stört, ist die Tatsache, das nur “irgendwelche” Bugs erwähnt werden, aber nicht genauer bezeichnet.
Denn dann könnte man ja mal suchen…
Damit wird man beim SUSE Support auch nicht weit kommen.
Bei der random hingeworfenen Clamav Schwachstelle konnte man anhand der CVEs nachvollziehen, dass für jeden einzelnen ein SUSE Bugreport erstellt wurde. Am Tag des Erscheinens. Dann ist es auch nur logisch, dass vom Support unnötige Duplikate geschlossen werden.
Auch von zahlenden Kunden sollte man erwarten können, dass sie mal im Bugzilla vorbeischauen, um unnötige Mehrarbeit beim Support und Duplikate zu vermeiden….
Aber alle Leap 16.0 RPM tragen doch sicher nicht die Versionsbezeichnung -bp157 bzw -150700 oder gibt es da ein Gegenbeispiel ?
Ich sehe die Frage ob ein RPM nun SLES oder Leap oder sonst was ist eigentlich pragmatisch aber für SLES 15 SP7 wird es halt nicht so viel Überschneidungen mit aktuellen openSUSE Versionen geben.
Es gibt ja keine Informationen um welches Kernel Problem es nun konkret geht aber Backports für den älteren Kernel von SLES 15 können halt schnell sehr aufwändig werden. Und die bemängelte Behandlung von Duplicates ist meiner Meinung nach schon sinnvoll. Das bedeutet ja nicht das es dann keinen Fix für das Problem geben wird.
Ich verwende kein SUSE Produkt sondern Leap 16.0 und ich fand den Start dieser Version zwar nicht ganz optimal aber beim Beheben von Security Problemen insbesondere beim Kernel habe ich nichts wesentliches zu bemängeln.
Na ja vielleicht gibt es ja forensische Linguisten im Forum die das anhand des Texts feststellen können. Das ist auch nicht viel unwahrscheinlicher als eine Problemlösung für ein Layer 7 Problem mit dem SUSE Support von diesem Forum zu erwarten.
Ich verwende kein SUSE Produkt sondern Leap 16.0 und ich fand den Start dieser Version zwar nicht ganz optimal aber beim Beheben von Security Problemen insbesondere beim Kernel habe ich nichts wesentliches zu bemängeln.
Dann wäre es wohl höchste Zeit die Wohlstandsblase durchzustechen und zu realisieren, dass die OpenSUSE Community offensichtlich mangels Manpower nicht in der Lage ist, bekannte Sicherheitslücken (zeitgerecht) in OpenSUSE Leap 16.x zu schliessen. Insbesondere in LibreOffice klaffen schon seit Monaten bekannte Sicherheitslücken. Siehe: https://forums.opensuse.org/t/leap-16-0-firefox-and-libreoffice-updates/194543
Wann kommt (endlich) das LibreOffice-Update auf Version 26.2.4 oder höher in den offiziellen Paketdepots (Repositories) von OpenSUSE Leap 16.0? Gemäss: https://download.opensuse.org/distribution/leap/16.0/repo/oss/x86_64/
trägt die aktuellste LibreOffice-Version aus den offiziellen Paketdepots für OpenSUSE Leap 16.0 die Versionsnummer 25.2.5.2-bp160.1.2 und trägt einen Zeitstempel vom September 2025.
Konsistent? Ja. Aber auch falsch. openSUSE ist ein ™ und soll geschrieben werden wie den ™. Genau so wie “Coca Cola” und kein "Coca-Cola, Cocacola usw.
Ach so, über die Qualität des Supports kann man sich nur beschweren, wenn man einen Premium Support Vertrag hat? Aus meiner Erfahrung braucht man das gerade dann nicht, weil das Gegenüber da zuhört.
