Un logiciel qu’on croyait condamné : l’évolution continue de relayd(8) et httpd(8)

 (rsadowski.de)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le développement de relayd(8) et httpd(8), qui stagnait à mesure que l’intérêt des développeurs historiques d’OpenBSD diminuait, est redevenu actif grâce à la participation de contributeurs confrontés à de vrais besoins en production
  • À l’heure où les LLM semblent remplacer le savoir-faire en programmation, le point de départ a été la conviction qu’il fallait apprendre et pratiquer le C soi-même ; la modernisation a donc commencé par le système imsg artisanal de relayd(8)
  • La plupart des correctifs non intégrés sur la mailing list tech@ entre 2024 et 2026, ainsi que les anciens tickets du miroir GitHub existant, ont été passés en revue et traités ; un miroir Git et un README ont aussi été mis en place pour aider les nouveaux contributeurs
  • relayd(8) a reçu une API imsg plus sûre, des renforcements de sécurité pour TLS et l’analyse des requêtes, ainsi que la correction de collisions au rechargement ; httpd(8) a ajouté une protection contre le request smuggling, des en-têtes personnalisés et le contrôle du cache pour les fichiers statiques
  • La sécurité, la stabilité et l’extensibilité des deux démons ont progressé ensemble, mais le travail a aussi fait grossir le backlog, et les idées comme les retours restent bienvenus

Pourquoi relancer un projet délaissé

  • Comme évoqué dans les principaux changements d’OpenBSD 7.8, le développement de relayd(8) et httpd(8) était à l’arrêt
    • Plusieurs contributeurs envoyaient des correctifs sur la mailing list tech@, mais presque aucun n’était intégré au dépôt
    • La cause principale était que les développeurs historiques d’OpenBSD ne s’intéressaient plus vraiment à ces deux démons
  • Le développement a repris de manière active sur la base d’une utilisation régulière des deux démons avec kirill@ et d’une expérience concrète sur des cas d’usage réels
    • La nécessité opérationnelle de prendre en charge des clients OpenBSD avec des configurations complexes de httpd(8) et relayd(8) a aussi été un moteur direct

Pourquoi revenir au C à l’ère des LLM

  • Le plus grand déclencheur a été l’arrivée des LLM
    • Autrefois, l’auteur écrivait du code C++ moderne de façon spécialisée, puis a évolué vers l’architecture de solutions, le platform engineering et la constitution d’équipes, au point d’écrire très peu de code au quotidien
    • Son activité se limitait surtout à écrire du YAML déclaratif et à lire / porter du code pour ports(7) d’OpenBSD
  • Contrairement à l’idée selon laquelle « le codage est résolu », il a estimé que, plus le savoir est délégué à l’extérieur, plus il devient important de le posséder soi-même
  • C++ et Rust prennent en charge une partie des arbitrages difficiles, mais ce n’est pas le cas du C ; ce défi a motivé la décision de contribuer à relayd(8) et httpd(8)

Une contribution portée par la discipline plus que par la motivation

  • Contribuer à l’open source peut se transformer en frustration au bout de quelques semaines, mais après une phase initiale pénible, il a été possible d’atteindre un rythme de travail durable
  • Au départ, la lecture passive de la base de code a souvent été décourageante
    • En cause : un manque de commentaires, certains choix de conception discutables et un code très imbriqué ; il reste difficile de savoir si cela tient à la nature du code C ou à un manque d’expérience personnelle
  • Après discussion avec les mainteneurs des démons OpenBSD, la décision a été prise de moderniser le système de messages imsg fait maison
    • Le travail a d’abord porté sur relayd(8), avant d’être étendu à httpd(8)
    • La modernisation elle-même a servi d’outil pour mieux comprendre la base de code

Tri des correctifs non intégrés et des anciens tickets

  • Les archives de la mailing list tech@ de 2024 à 2026 ont été examinées pour recenser les correctifs et problèmes non traités, et la plupart semblent désormais pris en charge
  • Les deux démons ont été développés à l’origine par Reyk Floeter, aujourd’hui retiré d’OpenBSD
  • Les anciens tickets du miroir GitHub de relayd géré par Reyk ont aussi été passés en revue
    • Tous les tickets sont maintenant soit fermés, soit corrigeables, et certains ne sont plus valides

Un miroir Git pour les nouveaux contributeurs

  • Inspiré par le miroir GitHub existant, un miroir séparé a été mis en place pour faciliter l’arrivée de nouveaux et jeunes contributeurs et créer un point de contact avec la communauté au-delà des mailing lists OpenBSD
  • L’arbre CVS est utilisé comme miroir Git, le développement étant d’abord mené sur une instance Gothub avant synchronisation vers les autres dépôts
  • La même approche a été appliquée à httpd(8), avec la rédaction d’un README.md détaillé contenant les informations nécessaires

Modernisation de relayd(8) et qualité du code

  • Le système imsg a été converti vers des accesseurs plus sûrs : imsg_get_data, imsg_get_type, imsgbuf_get
  • Une gestion d’erreurs appropriée a été ajoutée à tout le processus de lecture des payloads imsg
  • La journalisation et les commentaires ont été harmonisés avec bgpd
  • Le traitement de la ligne de début HTTP a été isolé dans une fonction dédiée pour améliorer l’organisation du code
  • Le format knfmt a été appliqué

Renforcement de la sécurité de relayd(8)

  • La suite de chiffrement TLS par défaut est passée de HIGH:!aNULL à secure
  • La prise en charge de ECDSA a été ajoutée au moteur de séparation de privilèges (privsep) de l’autorité de certification
  • Les en-têtes Content-Length dupliqués sont rejetés avec une réponse HTTP 400
  • Les en-têtes obs-fold ne sont pas autorisés afin d’éviter des divergences d’analyse, conformément à la RFC 9112 5.2
  • L’ID de processus est vérifié et IMSG_CTL_PROCFD est limité au processus parent
  • explicit_bzero est utilisé pour effacer les données sensibles comme les mots de passe

Corrections de bugs et améliorations de stabilité de relayd(8)

  • Une condition de concurrence au rechargement provoquant des plantages a été corrigée
  • Plusieurs fuites mémoire liées à X509_dup, config_purge et tls_cfg ont été supprimées
  • Des vérifications de NULL et de bornes ont été corrigées
  • Une gestion d’erreurs appropriée a été ajoutée aux échecs OpenSSL
  • La file d’erreurs OpenSSL est désormais vidée en cas d’échec TLS

Nouvelles fonctions ajoutées à relayd(8)

  • Prise en charge de la méthode HTTP MKCALENDAR
  • Possibilité d’utiliser TLS sur plusieurs listeners
  • Prise en charge de plusieurs adresses résolubles par nom
  • Définition explicite possible des chemins des certificats, des clés et des OCSP staples
  • Définition de User-Agent pour les requêtes de vérification d’état HTTP
  • Traitement correct des réponses HTTP sans corps

Modernisation de httpd(8) et qualité du code

  • proc.c a été converti à la nouvelle API imsg pour rester cohérent avec relayd(8)
  • L’ordre des tokens a été modifié afin de faciliter l’extension future des options de configuration
  • La journalisation a été harmonisée avec bgpd
  • Le code dupliqué et les fonctions vides ont été supprimés
  • Le format knfmt a été appliqué
  • Le traitement des fonctionnalités intégrées a été isolé dans une fonction dédiée

Renforcement de la sécurité de httpd(8)

  • La suite de chiffrement TLS par défaut est passée de compat à secure
  • Le framing de requête CL.TE est rejeté afin d’empêcher les attaques de request smuggling
  • Les en-têtes obs-fold reçoivent une réponse HTTP 400 conformément à la RFC 9112 5.2
  • La présence simultanée des en-têtes Content-Length et Transfer-Encoding est traitée comme une erreur
  • Un relink aléatoire est effectué au démarrage pour ajouter une protection supplémentaire
  • L’ID de processus est vérifié et IMSG_CTL_PROCFD est limité au processus parent
  • Une option no banner a été ajoutée pour masquer les informations d’identification du serveur dans les réponses

Corrections de bugs et améliorations de stabilité de httpd(8)

  • Le traitement des suffix ranges dans les requêtes HTTP a été corrigé
  • server_http_time() a été corrigé pour afficher correctement l’heure GMT
  • Les erreurs de timegm(3) sont désormais vérifiées conformément à la spécification du manuel
  • Les problèmes d’upload utilisant chunked transfer-encoding ont été résolus
  • Correction pour éviter l’envoi en double de fcgiparams dans une location
  • Une gestion d’erreurs appropriée a été ajoutée à dispatch_parent
  • Les réponses interrompues sont désormais correctement vidées via bufferevent
  • Les écritures inutiles signalées par scan-build ont été supprimées
  • return_uri_len est désormais validé avant la copie des données

Nouvelles fonctions de httpd(8) et travail restant

  • Prise en charge des en-têtes HTTP personnalisés
  • Héritage de gzip-static dans les locations pour un meilleur héritage de configuration
  • Extension des flags serveur à un entier 64 bits afin d’accepter davantage d’options
  • Ajout du contrôle du cache pour les fichiers statiques
  • Au fil du travail, le backlog s’est étoffé, et les idées comme les retours pour la suite du développement restent bienvenus

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • La prise en charge des en-têtes HTTP personnalisés est une bonne nouvelle. Auparavant, faute de cette fonctionnalité, on ne pouvait pas utiliser httpd même pour des usages simples ; c’est donc appréciable qu’elle soit désormais prise en charge.

  • Le développement de relayd(8) et httpd(8) était au point mort, et plusieurs contributeurs avaient soumis des patchs sur la liste de diffusion tech@, mais très peu avaient été intégrés au dépôt. Il semble que la raison principale soit que les développeurs OpenBSD existants ne s’intéressaient plus vraiment à ces démons ; merci donc à ceux qui ont repris la maintenance.

  • J’utilise régulièrement ces deux logiciels, et je suis content de les voir à nouveau correctement maintenus. Je n’avais absolument pas conscience que leur développement était au point mort.
    Grâce à leur structure logicielle simple, il semble avoir été possible de relancer le développement sans grande équipe et d’intégrer autant de fonctionnalités et de correctifs.

  • Les chiffres après les noms de logiciels m’ont longtemps paru déroutants, jusqu’à ce que je comprenne qu’il s’agit des numéros de section du manuel.
    1 désigne les programmes exécutables et commandes shell, 2 les appels système, 3 les appels de bibliothèque, 4 les fichiers spéciaux, 5 les formats de fichiers et conventions, 6 les jeux, 7 divers, 8 les commandes d’administration système, et le 9 non standard les routines du noyau.

    • Il suffit d’exécuter man 1 man, ou plus brièvement man man, pour consulter man(1). Les différentes pages intro mentionnées dans SEE ALSO sont particulièrement utiles.

  • Je me demande si ces améliorations seront incluses dans OpenBSD 8.0.

  • Je me demande si le lien a vraiment été conçu pour être lisible. Sur Firefox pour Android, il apparaît comme ceci :
    https://imgur.com/a/oTimS9R