Contexte et architecture du projet
Le produit commercial marketyour.games repose sur la pile BCHS : OpenBSD, le langage C, le serveur httpd d’OpenBSD et SQLite. Aucun framework n’est utilisé ; le programme C lit directement les variables d’environnement CGI et génère le HTML en sortie. La spécification CGI 1.1, publiée en 2004, n’a pas évolué depuis, ce qui garantit une interface stable et indépendante du langage.
Les seules dépendances externes sont libcurl (pour les appels à Stripe et Postmark), libsodium (génération d’identifiants aléatoires, hachage de mots de passe, vérification HMAC) et libcjson (parsing JSON). libcjson est fourni sous forme d’un unique fichier C, tandis que SQLite est intégré via son amalgamation officielle, également un seul fichier C. Le binaire final est statiquement lié, ce qui élimine toute dépendance dynamique au moment de l’exécution.
Mise en œuvre et processus de déploiement
Chaque requête HTTP déclenche la création d’un nouveau processus par le serveur httpd, qui exécute le binaire CGI dans un chroot par défaut. OpenBSD offre les primitives pledge et unveil pour restreindre les capacités du processus, limitant ainsi la surface d’attaque. Le binaire contient également tous les actifs statiques (images, CSS) compilés en mémoire, ce qui supprime le besoin d’un serveur de fichiers séparé.
Le déploiement consiste à remplacer le fichier binaire unique. Aucun redémarrage du serveur n’est requis ; les nouvelles requêtes utilisent immédiatement la version mise à jour, assurant ainsi une continuité de service sans temps d’arrêt. La compilation complète dure quelques secondes, et une reconstruction complète s’effectue en moins de 0,5 s, ce qui rend les itérations rapides.
Analyse des avantages techniques
Le modèle CGI élimine la couche d’inversion de contrôle typique des architectures « nginx + application server ». Le serveur web et la logique métier sont donc clairement séparés : httpd gère le transport, le binaire C gère la logique. Cette séparation simplifie le débogage ; le programme peut être exécuté depuis le shell, les entrées HTTP étant injectées via des variables d’environnement, et il est possible d’utiliser gdb, valgrind ou les sanitizers sans configuration supplémentaire.
Du point de vue de la chaîne d’approvisionnement, le projet ne dépend que d’un compilateur C et de trois bibliothèques. Compromettre le système nécessiterait de compromettre libcurl ou libsodium, deux projets largement audités, contrairement à des stacks modernes où une seule dépendance peut entraîner des centaines de sous‑dépendances non vérifiées.
Limites et points d’amélioration
CGI ne fournit aucune abstraction pour la gestion des cookies, le parsing des paramètres de requête ou l’échappement du contenu HTML. L’auteur a implémenté ces fonctions dans un unique fichier d’en‑tête (cgi.h), mais cela augmente la charge de maintenance. Des bibliothèques comme kcgi existent, mais leur adoption introduirait de nouvelles dépendances, ce qui irait à l’encontre de la philosophie de minimalisme du projet.
Enfin, le modèle de processus par requête implique une surcharge système proportionnelle au nombre de requêtes simultanées. Sur des charges très élevées, le coût de création de processus peut devenir un goulot d’étranglement, nécessitant éventuellement un serveur de pré‑fork ou une migration vers un modèle d’événements asynchrones.
