@fdsonne : Während ich Deiner Aussage weitestgehend zustimmen kann, habe ich doch eine kleine Ergänzung. Der Verzicht auf Software-Updates (und lediglich Sicherheits-Patches) ist nicht nur im Hinblick auf funktionale Änderungssicherheit (Stabilität) ein wichtiger Kernpunkt der Sicherheitsstrategie. Viele, gerade jüngere Devs glauben, nur regelmäßig aktualisierter Code ist ein Zeichen für hohe Sicherheit. Das ist aber Quatsch.
Ich bin mir grade nicht sicher, wie das Programm hieß... QMail? Irgend ein Linux Mail-Programm jedenfalls. Da gab es abgesehen von ein paar initialen Updates (zur Feature-Komplettierung) viele Jahre keinerlei Updates mehr. Warum? Nun, weil das Programm schlicht sicher gebaut war. Unsicher waren lediglich die Libraries drumherum.
Auch statistisch ist nachgewiesen, dass ein neueres Software-Release neue Softwarefehler implementiert. Sei es, durch fehlerhaftes Refaktoring, fehlerhafte Patch-Implementierung (berüchtigtes Wiederauftreten eigentlich schon gefixter Bugs) oder schlicht Fehler in neuem Code. Daher ist immanent, dass lediglich Sicherheitspatches bei ansonsten gleicher Code-Basis weniger Fehler erzeugen, als Sicherheitspatches via Software-Releaseupdate.
(Mal ganz davon ab, dass theoretisch JEDES neue Software-Release EINES Programmes an ganz verschiedenen Stellen im System Dinge kaputt machen kann, weil API-Syntax oder sonstige Ein- oder Ausgaben oder auch nur Laufzeit-Quirks sich zur vorherigen Version verändert hat.. Auch DAS erspart man sich dadurch. Mehrkosten hat das Debian-Team lediglich dadurch, dass sie Sicherheitspatches, die ggf. nur gegen neuere Software-Versionen effizient sind, auf ihren "alten" Software-Stand zurückportieren müssen. - Ein kleineres Übel.
)
Regards, Bigfoot29
Nachtrag:
@ropf : Diese Code-Scanner gibt es. Sowohl klassisch als auch mit KI-Ansätzen. Klassische Scanner funktionieren entweder nach dem Prinzip des "Ich mülle das Programm mit Eingangsdaten zu und schaue mal, bei welchen es kotzt" oder eben dem Prinzip der wirklichen Code-Scanner, die ein eingebautes Regelset haben, was potentiell gefährlich oder "schlechte Praxis" ist.
ABER:
1) Die Nutzung dieser Programme kostet Zeit (für die Einarbeitung des DEVs in den Code-Scanner sowie reguläre Ausführungszeit) und Geld (Lizenzen oder schlicht Rechenzeit irgendwo)
2) Und viel schlimmer: Anders als viele glauben, werden bei weitem nicht alle Bugs gefixt. Jeder nicht gefundene Fehler ist ein Code-Fragment, dass nicht geschrieben werden muss. Oft gilt daher: "Works as designed und raus an den Kunden! Der meldet sich dann schon." Auch in freier Software werden bei WEITEM nicht alle Fehler behoben. Wer das nicht glaubt, darf gern mal bei beliebigen OSS-Programmen (Kernel, Firefox, Nextcloud, ...) in die öffentlich einsehbaren Bugtracker gucken. Da gammeln Hunderte Fehlermeldungen vor sich hin. Die Kappa (Muskelkraft) zum Beheben fehlt aber. Daher werden nur die schlimmsten Bugs behoben. Der Rest wartet, bis irgend wann am St.Nimmerleinstag mal doch jemand Zeit findet, kleinere Auffälligkeiten zu beheben.
3) Kotzen die DEVs gerade massiv über KI im Code-Scanning ab. KI halluziniert. Sie KANN kein richtig von falsch unterscheiden. Sie sagt/tut Dinge, die - vereinfacht gesagt - prozentual für den nächsten Schritt am wahrscheinlichsten (und nicht am logischsten) sind. Das funktioniert für Text Ein-/Ausgabe und Sprache relativ gut, da das ein vergleichsweise kleines Aufgabengebiet ist. Aber für nahezu beliebig komplexe Dinge wie Code KANN KI gar nicht ausreichend "wahrscheinlich korrekt" sein. Daher sind viele der KI-basiert gefundenen Bugs schlicht Fakes. Das kostet dann extra Zeit für die Devs, herauszufinden, dass der Fehler eben NICHT echt ist. Denn gemäß plausibel klingender KI-Meldung IST der Code ja kaputt. Nur passt das nicht zur Realität und lässt sich daher unheimlich schwer auf einfache Art als Fehl-Meldung beweisen.
