Wie (und warum) ein TuxCare-Teammitglied zu Open-Source-Software beiträgt

In einigen unserer früheren Artikel haben wir die enge Beziehung zwischen Open-Source-Software - die im Wesentlichen kostenlos ist - und den kommerziellen Unternehmen, die sich auf Open-Source-Software stützen, behandelt.

Einer der Punkte, die wir angesprochen haben, ist, dass es üblich ist, dass Mitarbeiter, die von kommerziellen Organisationen bezahlt werden, zu Open-Source-Projekten beitragen, ohne dass ihr Arbeitgeber einen direkten finanziellen Nutzen aus dieser Arbeit zieht.

Für diese Großzügigkeit gibt es eine Reihe von Beweggründen. Manchmal muss ein kommerziell orientiertes Unternehmen einfach aus Eigeninteresse Funktionen zu einem Open-Source-Projekt hinzufügen. Oft geht es aber auch um die symbiotische Beziehung zwischen den Nutzern von Open-Source-Software - und der Open-Source-Gemeinschaft.

Für diesen Artikel haben wir mit einem der Entwickler des TuxCare-Teams - Dmitry Antipov - gesprochen, um herauszufinden, wie das TuxCare-Team zu Open Source beiträgt. Lesen Sie weiter, um zu erfahren, wie Dmitry bei seiner täglichen Arbeit bei TuxCare mit Open-Source-Software arbeitet und was die Beweggründe für TuxCare und Dmitris Beiträge zu Open-Source-Software sind.

Kennzeichnung eines Schlüsselproblems in RPM

Dmitry begann 1998 als Software-Ingenieur zu arbeiten. Er arbeitete hauptsächlich an einer Reihe von Linux-Projekten, darunter der Linux-Kernel und eine Reihe von anderen allgemeinen Systementwicklungsaufgaben. Ein Großteil dieser Erfahrung wurde in der Unternehmensumgebung gesammelt. Derzeit arbeitet Dmitry im Extended Lifecycle Support (ELS)-Team bei TuxCare, aber er trägt auch zu einer Reihe von Open-Source-Projekten während seiner täglichen Arbeit bei TuxCare bei.

Manchmal ergibt sich diese Arbeit aus einem beobachteten Bedarf. Nehmen wir den Fall der RPM-Pakete. Einem Community-Mitglied ist aufgefallen, dass bei RPM-Paketen widerrufene Unterschlüssel nicht überprüft werden, wenn ein Paket auf eine gültige Signatur geprüft wird. Selbst wenn also ein Unterschlüssel widerrufen wurde, wird er immer noch akzeptiert.

Dies veranlasste Dmitry, das Problem zu untersuchen - ein ziemlich kritisches Problem, da Benutzer von RPM-basierten Linux-Distributionen jahrelang Pakete installiert haben könnten, deren Signaturen nicht korrekt validiert waren.

Glück - für den Moment

Während sowohl RPM als auch libdnf prüfen, ob ein Schlüssel gültig und nicht abgelaufen ist, prüft keiner von beiden, ob er widerrufen wurde. Glücklicherweise wurde keine der RPM-Distributionen von einem auf dieser Schwachstelle basierenden Angriff getroffen.

Laut Dmitri war es im Wesentlichen Glück, dass die Schlüssel nicht widerrufen werden mussten, wie es beim Hack der Norton-Zertifizierungsstelle der Fall war. Und folglich wurden die zum Signieren von RPM-Paketen verwendeten Schlüssel ordnungsgemäß gespeichert und nie widerrufen.

Dmitri sagt, dass ein Teil des Problems darin besteht, dass sich Paketverwaltungsprojekte auf die Paketverwaltung und nicht auf die Kryptographie konzentrieren. Das ist zu erwarten, und es gibt wenig Bedarf für RPM, seine eigenen Krypto-Bibliotheken einzurichten. Nichtsdestotrotz wies Dmitri auf das Problem hin, und zu gegebener Zeit wird sich das Team hinter der RPM-Paketverwaltung damit befassen, obwohl es eine offene Frage ist, wann dies geschehen wird.

Beitrag zu GlusterFS

Einer der stärksten Aspekte der Open-Source-Gemeinschaft ist die Tatsache, dass sie mit innovativen, von der Gemeinschaft betriebenen Projekten immer wieder auf die neuesten technologischen Anforderungen reagiert.

GlusterFS ist eines dieser Projekte. Um den Anforderungen von konstant skalierten verteilten Serverumgebungen gerecht zu werden, begann ein Team von Anwendern mit dem Aufbau eines verteilten Dateisystems, das beliebig skaliert werden kann.

Das Dateisystem kann mehrere Petabytes an Speicherplatz für Hunderte von Notizen verwalten und ist eine beliebte Lösung für Backend-Speicher in verteilten virtuellen Umgebungen. Wie bei allen anderen Open-Source-Projekten ist jedoch auch bei GlusterFS ein kontinuierlicher Beitrag der Community erforderlich. Immerhin ist es schon über ein Jahrzehnt alt.

Im Gespräch mit Dmitri stellte sich schnell heraus, dass er auf wichtige Weise zu GlusterFS beiträgt. Seit einiger Zeit arbeitet Dmitri an den unteren Schichten des GlusterFS-Systems, wo die High-Level-Systemlogik auf das Betriebssystem trifft. Dazu gehört die Arbeit an Dateien, Sockets, Threads, Synchronisation, etc. In jüngster Zeit hat er sich mit einigen Problemen im Zusammenhang mit nicht initialisierten Mutexen beschäftigt, die immer noch verwendet werden. Obwohl dies etwas ist, das ein Tool wie valgrind leicht genug erkennen kann, hat es dennoch seinen Weg in die Codebasis gefunden. Er hat auch einige Probleme im Zusammenhang mit der Thread-Finalisierung behoben, bei denen einige beendete Threads den Stack nicht korrekt freigaben, was zu Speicherlecks führte.

Behebung des wachsenden Problems mit Mutexen

Unsere regelmäßigen Leser werden bemerkt haben, dass wir in letzter Zeit über eine Reihe von Sicherheitslücken berichtet haben und dass Bedenken bezüglich der Verwendung von Mutexes und Futexes aufkamen, wobei mehrere CVEs auf Fehler bei ihrer Verwendung hinwiesen.

In der Tat drehten sich einige von Dmitrys Beiträgen zu GlusterFS um Mutexe - er versuchte, Probleme mit Ressourcenlecks zu lösen. Laut Dmitry sollten Mutexe, wenn sie nicht mehr benötigt werden, freigegeben werden - andernfalls entsteht ein kleines, aber sichtbares Ressourcenleck. Das ist zwar nicht so gravierend wie ein Speicherleck, aber es besteht immer noch die Notwendigkeit für saubere Programmierpraktiken - und die Ressourcen sollten nach der Verwendung immer aufgeräumt werden.

Arbeit an Open Source innerhalb von TuxCare

RPM und GlusterFS sind nur zwei Beispiele für Dmitris Beiträge in der Open-Source-Gemeinschaft. Das Interessante an der Arbeit unseres Entwicklers ist die Tatsache, dass sie fast seine gesamte Zeit bei TuxCare in Anspruch nimmt.

Mit anderen Worten: Dmitri arbeitet hauptsächlich an Open-Source-Projekten mit, obwohl er im Extended Lifecycle Support (ELS)-Team tätig ist. Wir haben Dmitri gefragt, wie das mit den Vorrechten einer kommerziellen Organisation zusammenpasst.

Laut Dmitri will TuxCare als wertvolles Mitglied der Open-Source-Bewegung angesehen werden, und der Antrieb, Beiträge zu Open-Source-Projekten zu leisten, kommt von der Managementebene. Durch die gemeinsame Nutzung von Code zur Behebung von Problemen, die in den von ELS abgedeckten Linux-Distributionen identifiziert wurden, mit Upstream-Projekten, werden diese Fehlerbehebungen für alle verfügbar und tragen so zu einer insgesamt sichereren IT-Umgebung bei.

Dmitri sagt, dass er wahrscheinlich weiterhin zu Open-Source-Projekten beitragen wird, und fügt einer langen Liste von bestehenden Beiträgen hinzu, die neben dem, was wir bereits erwähnt haben, auch eine Dateisystem-Backend-Synchronisation auf der Basis von POSIX AIO und eine verbesserte Unterstützung für die Ausführung verschiedener Valgrind-Prüfer umfasst.

Die Geschichte von Dmitri a TuxCare zeigt, wie kommerzielle Anbieter eng mit Mitgliedern der Open-Source-Community zusammenarbeiten, um zu Open-Source-Projekten beizutragen. Gemeinsam treiben wir das Open-Source-Projekt voran - und sorgen dafür, dass sich alle Organisationen, ob staatlich, nichtstaatlich oder gewinnorientiert, weiterhin auf eine leistungsfähige, sichere Open-Source-Codebasis verlassen können.