Ich wäre vorsichtig mit Aussagen darüber, was offensichtlich passiert ist oder nicht passiert ist. Das wissen wir nicht.
Doch das wissen wir sehr genau und alle Firmenkunden des Unternehmens wissen das mittlerweile auch: es wurde kein (Integrations-)Test für dieses Update durchgeführt. Weder automatisch, noch händisch. Ein andere logische Erklärung (außer eben "Manipulation") gibt es nicht.
Menschliche Code-Reviews schließen im Übrigen nicht zwingend die Ausführung von Code ein, dazu kann auch einfach nur der Code gelesen werden.
Ein Treiberupdate (auch die Änderung einer Konfigurationsdatei ist ein Treiberupdate) welches im Kernel eines OS residiert wird sicher nicht getestet, indem ich nur den "Code lese". Der eigentlich verursachende Agent, welcher den Fehler enthielt, wurde als Herzstück der Endpunkt-Überwachung vermutlich vorher schon etliche Male Code-gereviewed . Dass man da so einen Fehler noch nicht findet, ist etwas, was wirklich häufiger passiert und "normal" gewesen wäre, da hier ja viele Komponenten auf den Zielrechnern zusammenspielen müssen. Bei der Änderung an der Definitionsdatei sehe ich ja auch nur einen geänderten Datensatz.
Die Ausführung erfolgt dann eher im Rahmen der sogenannten Continuos Integration (CI). Aber da kann es auch vorkommen, dass ein bestimmter Fall nicht abgedeckt ist. Oder abgedeckt ist, aber der Test fehlerhaft ist und ein falsches Ergebnis liefert. Oder die Testumgebung verhält sich anders als das Gerät des Entwicklers. Das kommt in der realen Welt alles vor.
Auch da sind Tests zwingend vorgeschrieben. Welcher Fall soll denn da nicht abgedeckt worden sein? Man erwartet als absolutes Minimum bei einem Rollout eines Treiber(!)-Updates, dass dieses Update wenigstens einmal auf einem Windows-Testrechner eingespielt und durchgeführt wird. Also auf einem dieser stinknormalen Windows-Rechner, die CrowdStrike dann millionenfach stillgelegt hat. Da ist der Rechner des Entwicklers absolut nebensächlich...
Das bestreitet doch überhaupt niemand. Im Gegenteil, ich schrieb das sogar selbst, dass das nicht passieren darf. Aber zwischen „darf nicht passieren“ und „es gab möglicherweise eine vorsätzliche Manipulation“ liegt ein himmelweiter Unterschied.
Ich habe nur im letzten Satz geäußert, dass der Verdacht bei so etwas entstehen kann, wenn man bei dem Versuch einer Erklärung nur zwei Möglichkeiten hat: Extreme "Stümperei"(m.M.n. zu 99% wahrscheinlich) oder eben Vorsatz. Ich habe meine Argumentation nicht daran aufgehängt.
Für eine Beurteilung, welche Bibliotheken eingesetzt oder nicht eingesetzt werden sollten, benötigt man ein bisschen mehr Kenntnis über das Gesamtprojekt und Entscheidungen, die in dessen Rahmen getroffen worden sind. Dazu kann ein Außenstehender keine qualifizierte Aussage treffen.
Die std-Bibliothek (früher STL) ist, wie der Name schon sagt, standardmäßig integriert. Mit den entsprechenden Headern und dem Auswählen des std:: Namensraums bzw. using habe ich Zugriff darauf. Ja, welche Funktionen und was konkret davon benutzt wurde, weiß momentan niemand. Ich hatte auch nur das wiedergegeben, was bekannt ist und extra dazugeschrieben:
Nur Vermutungen meinerseits ...
Ich nehme mir halt das Recht heraus in einem Off-Topic Beitrag auch Vermutungen zu formulieren, so wie du es in diesem Thread auch schon getan hast. Hier hatte ich das sogar explizit dazugeschrieben. Und wenn ich bei dieser expliziten Vermutung meine Meinung äußere, wie man Fehlerquellen minimieren (nicht gänzlich ausschließen!) kann, so wird einem das gleich als Klugscheißerei ausgelegt?!
Ja. In der Qualitätssicherung wurde versagt, hier muss nachgebessert werden.
Gut, da sind wir uns ja immerhin einig.