Software::Kernel
Signierte Patches im Linux-Kernel?
Die [a 0.5764]Diebstahl-Vorwürfe[/a] an die Linux-Entwickler könnten den zukünftigen Prozess der Entwicklung des Kernels ändern.
Linux, wie auch eine Vielzahl anderer Projekte, ist fast ausschließlich öffentlich entwickelt worden. Bedingt durch die große Anzahl der Entwickler, die nicht selten kompletten Zugriff auf die Quellen der Applikation haben, ergeben sich daraus allerdings auch Probleme. Die vorteilhafte öffentliche Entwicklung könnte, wie es SCO zu suggerieren versucht, auch Nachteile haben: Ungeprüfter Quellcode, sei es rechtlicher oder sicherheitsrelevanter Natur, kann unbemerkt in das System einfließen und zu späteren Problemen führen. Durch gezieltes Management kann allerdings auch dieses Risiko auf ein Minimum reduziert werden.
Wie die Entwickler von KDE bereits vor Wochen demonstrierten, ist es auch bei großen Projekten möglich, durch gezielte Überprüfung der Quellen schadhaften oder falschen Code zu entfernen. In dem gegebenen Fall versuchte ein russischer Hacker zu demonstrieren, wie einfach es sei, Code in ein Open-Source-Projekt einzuschleusen. Dazu implementierte er in den Quellcode von kppp einen Kommentar, in dem er erklärt, er wolle sehen, wie lange solche Änderungen unbemerkt blieben. Bereits nach zwei Stunden waren die Änderungen Geschichte.
Im Gegensatz zum KDE-Entwicklungsmodell, das eine regelmäßige, gegenseitige Kontrolle der Entwickler vorsieht, enthält der Kernel solche Mechanismen nicht. Lange Zeit ohne Versionskontrolle entwickelt, stellt sich die Verifizierung des Codes auch heute noch als sehr schwierig dar. Grund genug für den Vater von Linux, Linus Torvalds, eine Diskussion über ein neues Verifizierungsverfahren anzustoßen.
Torvalds schlug vor, eine Methode einzuführen, um eingereichte Patches zu signieren. Neben dem Autor der Änderung müssten noch weitere Programmierer wie der Autor das Systems, Maintainer des Subsystems und Linus die betreffenden Neuerungen »signieren«. Erst nachdem alle Beteiligten die Änderungen verifiziert haben und der Autor seine Änderungen im Sinne von Open Source deklariert hat, kann ein Patch in den Kernel eingebunden werden. Jede Einsendung könnte so auch Jahre später verifiziert werden.
Die Reaktionen auf den Vorschlag sind gemischt. Die meisten Hacker befürchten mehr Arbeit. Ferner halten viele Maintainer des Kernels die momentane Vorgehensweise für ausreichend. So werden Patches, bevor sie endgültig in den Kernel Einzug halten, in experimentelle Kernels eingebunden und können ausgiebig getestet werden. Ob die Testpersonen jede Zeile des neuen Codes einer Prüfung unterziehen, ist allerdings fraglich. Im Zuge der Diskussion ist allerdings eine Sache klar geworden: Die massiven Vorwürfe von SCO sind auch an den Linux-Hackern nicht spurlos vorbei gegangen.
