Tote Software auf Wanderschaft: die kontinuierliche Weiterentwicklung von relayd(8) und httpd(8)

 (rsadowski.de)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Entwicklung von relayd(8) und httpd(8), die ins Stocken geraten war, weil das Interesse der bisherigen OpenBSD-Entwickler nachließ, wurde durch Beiträge von Mitwirkenden mit realem Betriebsbedarf wieder belebt
  • Ausgangspunkt war die Einschätzung, dass man gerade in einer Zeit, in der LLMs Coding-Wissen ersetzen, selbst C lernen und sich der Herausforderung stellen sollte; zunächst wurde das handgemachte imsg-System von relayd(8) modernisiert
  • Von 2024 bis 2026 wurden die meisten nicht übernommenen Patches auf der Mailingliste tech@ sowie alte Issues des bestehenden GitHub-Mirrors abgearbeitet; außerdem wurden ein Git-Mirror und ein README für neue Beitragende eingerichtet
  • relayd(8) erhielt eine sichere imsg-API, verstärkte Sicherheit bei TLS und Request-Parsing sowie Fixes für Reload-Kollisionen; httpd(8) bekam Schutz vor Request Smuggling, benutzerdefinierte Header und Cache-Steuerung für statische Dateien
  • Sicherheit, Stabilität und Erweiterbarkeit beider Daemons wurden verbessert, zugleich wuchs während der Arbeit der Backlog; Ideen und Feedback sind weiterhin willkommen

Hintergrund: ein Projekt wiederbeleben, das das Interesse verloren hatte

  • Wie in den wichtigsten Änderungen von OpenBSD 7.8 beschrieben, war die Entwicklung von relayd(8) und httpd(8) ins Stocken geraten
    • Mehrere Beitragende hatten Patches an die Mailingliste tech@ geschickt, doch nur sehr wenige wurden ins Repository übernommen
    • Der Hauptgrund war, dass die bisherigen OpenBSD-Entwickler kein Interesse mehr an den beiden Daemons hatten
  • Auf Basis der Erfahrung, die beiden Daemons zusammen mit kirill@ regelmäßig zu nutzen und reale Anwendungsfälle zu betreuen, begann eine aktive Entwicklung
    • Auch der praktische Bedarf, OpenBSD-Kunden mit komplexen httpd(8)- und relayd(8)-Konfigurationen zu unterstützen, wurde zu einem direkten Antrieb

Warum in der LLM-Ära die Rückkehr zu C?

  • Der größte Auslöser war das Aufkommen von LLMs
    • Früher wurde professionell moderner C++-Code geschrieben, später verlagerte sich die Arbeit jedoch auf Solution Architecture, Platform Engineering und Teamaufbau, wodurch kaum noch echter Code geschrieben wurde
    • Die Tätigkeit beschränkte sich hauptsächlich auf deklaratives YAML sowie darauf, für OpenBSD ports(7) Code zu lesen und zu portieren
  • Entgegen der Behauptung, „Coding sei gelöst“, entstand die Einschätzung, dass es gerade in einer Zeit, in der Wissen nach außen delegiert wird, noch wichtiger ist, dieses Wissen selbst zu besitzen
  • Da C++ und Rust einem manche schwierigen Entscheidungen abnehmen, C jedoch nicht, wurde genau das als Herausforderung verstanden und die Entscheidung getroffen, zu relayd(8) und httpd(8) beizutragen

Beiträge durch Disziplin statt Motivation fortführen

  • Open-Source-Beiträge können nach wenigen Wochen in Frustration enden, doch nach der anfänglichen schmerzhaften Phase wurde ein Zustand erreicht, in dem kontinuierliche Arbeit möglich war
  • Anfangs wurde die Codebasis passiv gelesen, was an vielen Stellen entmutigend war
    • Gründe waren fehlende Kommentare, teils schlechtes Design und komplex verwobener Code; ob dies an den Eigenheiten von C-Code oder an mangelnder eigener Erfahrung lag, ist noch unklar
  • Nach Gesprächen mit den Maintainers der OpenBSD-Daemons wurde beschlossen, das handgebaute imsg-Nachrichtensystem zu modernisieren
    • Zunächst lag der Fokus auf relayd(8), anschließend wurde der Umfang auf httpd(8) erweitert
    • Die Modernisierung selbst wurde als Mittel genutzt, die Codebasis zu verstehen

Nicht übernommene Patches und alte Issues aufräumen

  • Die Archive der Mailingliste tech@ von 2024 bis 2026 wurden überprüft, um unbearbeitete Patches und Issues zu sammeln; die meisten gelten inzwischen als erledigt
  • Die beiden Daemons wurden ursprünglich von Reyk Floeter entwickelt, der mittlerweile bei OpenBSD im Ruhestand ist
  • Auch alte Issues im von Reyk gepflegten relayd-GitHub-Mirror wurden geprüft
    • Alle Issues können geschlossen oder behoben werden; einige sind nicht mehr gültig

Git-Mirror für neue Beitragende

  • Ausgehend vom bestehenden GitHub-Mirror wurde ein separater Mirror aufgebaut, um neuen und jüngeren Beitragenden den Einstieg zu erleichtern und Berührungspunkte mit Communities außerhalb der OpenBSD-Mailinglisten zu schaffen
  • Der CVS-Tree wird als Git-Mirror genutzt; die Entwicklung erfolgt zunächst auf einer Gothub-Instanz und wird anschließend mit den übrigen Repositories synchronisiert
  • Für httpd(8) wurde derselbe Ansatz angewendet und ein ausführliches README.md mit den nötigen Informationen geschrieben

Modernisierung und Codequalität von relayd(8)

  • Das imsg-System wurde auf die sichereren Accessors imsg_get_data, imsg_get_type, imsgbuf_get umgestellt
  • Im gesamten Ablauf des Lesens von imsg-Payloads wurde passende Fehlerbehandlung ergänzt
  • Logging und Kommentare wurden zur Konsistenz mit bgpd standardisiert
  • Die Verarbeitung der HTTP-Startzeile wurde in eine eigene Funktion ausgelagert, um die Codestruktur zu verbessern
  • Das knfmt-Format wurde angewendet

Sicherheitsverbesserungen in relayd(8)

  • Die standardmäßige TLS-Cipher-Suite wurde von HIGH:!aNULL auf secure geändert
  • Dem CA-Privilege-Separation-Engine wurde ECDSA-Unterstützung hinzugefügt
  • Doppelte Content-Length-Header werden mit HTTP 400 abgelehnt
  • Gemäß RFC 9112 5.2 werden obs-fold-Header nicht zugelassen, um Parser-Unterschiede zu verhindern
  • Prozess-IDs werden geprüft und IMSG_CTL_PROCFD wird auf den Elternprozess beschränkt
  • Zum Löschen sensibler Passwortdaten wird explicit_bzero verwendet

Bugfixes und Stabilitätsverbesserungen in relayd(8)

  • Eine Race Condition beim Reloading, die Abstürze verursachte, wurde behoben
  • Mehrere Memory Leaks im Zusammenhang mit X509_dup, config_purge und tls_cfg wurden beseitigt
  • NULL-Prüfungen und Bounds Checks wurden korrigiert
  • Für OpenSSL-Fehler wurde eine geeignete Fehlerbehandlung ergänzt
  • Bei TLS-Fehlern wird nun die OpenSSL-Fehlerqueue geleert

Neue Funktionen in relayd(8)

  • Die HTTP-Methode MKCALENDAR wird unterstützt
  • TLS kann nun auf mehreren Listeners verwendet werden
  • Mehrere auflösbare Adressen werden unterstützt
  • Pfade für Zertifikate, Schlüssel und OCSP-Staples können explizit gesetzt werden
  • Für HTTP-Healthcheck-Requests wird ein User-Agent gesetzt
  • HTTP-Antworten ohne Body werden korrekt verarbeitet

Modernisierung und Codequalität von httpd(8)

  • proc.c wurde auf die neue imsg-API umgestellt, um Konsistenz mit relayd(8) herzustellen
  • Die Token-Reihenfolge wurde geändert, damit sich künftige Konfigurationsoptionen leichter erweitern lassen
  • Das Logging wurde zur Konsistenz mit bgpd standardisiert
  • Doppelte Codeabschnitte und leere Funktionen wurden entfernt
  • Das knfmt-Format wurde angewendet
  • Die Verarbeitung integrierter Funktionen wurde in eigene Funktionen ausgelagert

Sicherheitsverbesserungen in httpd(8)

  • Die standardmäßige TLS-Cipher-Suite wurde von compat auf secure geändert
  • Zur Abwehr von Request-Smuggling-Angriffen wird CL.TE-Request-Framing abgelehnt
  • Gemäß RFC 9112 5.2 wird auf obs-fold-Header mit HTTP 400 geantwortet
  • Wenn Content-Length- und Transfer-Encoding-Header gleichzeitig vorhanden sind, wird dies als Fehler behandelt
  • Für zusätzlichen Schutz wird beim Booten zufälliges Relinking durchgeführt
  • Prozess-IDs werden geprüft und IMSG_CTL_PROCFD wird auf den Elternprozess beschränkt
  • Die Option no banner wurde hinzugefügt, um Server-Identifikationsinformationen in Antworten zu verbergen

Bugfixes und Stabilitätsverbesserungen in httpd(8)

  • Die Verarbeitung von Suffix Ranges in HTTP-Requests wurde korrigiert
  • server_http_time() wurde so behoben, dass es GMT-Zeit korrekt ausgibt
  • Fehler von timegm(3) werden gemäß Handbuchspezifikation geprüft
  • Probleme mit Uploads, die chunked transfer-encoding verwenden, wurden gelöst
  • Es wurde behoben, dass fcgiparams einer Location nicht zweimal gesendet werden
  • dispatch_parent erhielt eine geeignete Fehlerbehandlung
  • Abbruchantworten werden nun korrekt über bufferevent geleert
  • Von scan-build gefundene unnötige Speicherungen wurden entfernt
  • return_uri_len wird validiert, bevor Daten kopiert werden

Neue Funktionen und verbleibende Arbeiten in httpd(8)

  • Benutzerdefinierte HTTP-Header werden unterstützt
  • Für bessere Konfigurationsvererbung erben Locations gzip-static
  • Server-Flags wurden auf 64-Bit-Integer erweitert, um mehr Flag-Optionen aufzunehmen
  • Cache-Steuerung für statische Dateien wurde hinzugefügt
  • Je weiter die Arbeit voranschritt, desto größer wurde der Backlog; Ideen und Feedback für die künftige Entwicklung sind weiterhin willkommen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare

  • Unterstützung für benutzerdefinierte HTTP-Header ist erfreulich. Früher konnte ich httpd für einfache Zwecke nicht nutzen, weil diese Funktion fehlte, daher ist es gut, dass sie jetzt unterstützt wird

  • Die Entwicklung von relayd(8) und httpd(8) war ins Stocken geraten, und obwohl mehrere Mitwirkende Patches auf der Mailingliste tech@ veröffentlichten, wurde davon fast nichts ins Repository übernommen. Der Hauptgrund war offenbar, dass die bisherigen OpenBSD-Entwickler kein Interesse mehr an diesen Daemons hatten. Daher bin ich dankbar, dass jemand die Wartung übernommen hat

  • Ich nutze beide Programme regelmäßig und freue mich, dass sie wieder ordentlich gepflegt werden. Dass die Entwicklung ins Stocken geraten war, wusste ich überhaupt nicht
    Dank der einfachen Softwarestruktur scheint es möglich gewesen zu sein, die Entwicklung auch ohne großes Team wieder in Gang zu bringen und so viele Funktionen und Korrekturen einzupflegen

  • Die Zahl hinter dem Softwarenamen hat mich eine Zeit lang verwirrt, aber dann habe ich gelernt, dass sie sich auf die Abschnittsnummer des Handbuchs bezieht
    1 steht für ausführbare Programme und Shell-Befehle, 2 für Systemaufrufe, 3 für Bibliotheksaufrufe, 4 für spezielle Dateien, 5 für Dateiformate und Konventionen, 6 für Spiele, 7 für Sonstiges, 8 für Systemverwaltungsbefehle, und das nicht standardisierte 9 für Kernel-Routinen

    • Man kann man 1 man oder kurz man man ausführen und sich man(1) ansehen. Besonders nützlich sind die verschiedenen intro-Seiten unter SEE ALSO

  • Ich frage mich, ob diese Verbesserungen in OpenBSD 8.0 enthalten sein werden

  • Ich frage mich, ob der Link ursprünglich lesbar gestaltet wurde. In Firefox für Android sieht er so aus
    https://imgur.com/a/oTimS9R