Ajoutez des modules à un serveur Go sans affaiblir la sécurité

## Gardez des réglages par défaut sûrs et décidez où placer chaque nouvelle fonction Considérez les paramètres sécurisés par défaut comme la principale exigence produit d’une plateforme de serveur exposée à Internet. Concevez les fonctions comme des modules composables au lieu de les coupler étroitement au noyau. Préférez les extensions générales qui répondent à une catégorie de cas d’usage aux correctifs destinés à un seul déploiement. Déterminez si une modification relève d’une application de premier niveau, d’un module réutilisable, d’une adaptation de configuration ou du point d’entrée en ligne de commande. Conservez les identifiants de modules dans des espaces de noms afin que les composants développés indépendamment n’entrent pas en collision. Préservez un modèle natif de configuration structurée même lorsque des adaptateurs conviviaux sont disponibles. Examinez avec une attention accrue le traitement des requêtes, la sécurité du transport, l’identité, la gestion des certificats et les limites de confiance. Retracez le comportement sensible à la sécurité dans les dépôts ou paquets associés lorsque la responsabilité est distribuée. Ne considérez pas une modification critique pour la sécurité comme prête à fusionner tant que ses limites de confiance et ses modes de défaillance affectés ne sont pas compris. Maintenez le registre des modules standard explicite afin que les composants distribués puissent être découverts et audités. Veillez à ce que les exécutables de commande importent l’ensemble de modules prévu au lieu de dépendre d’un enregistrement accidentel. Documentez l’emplacement architectural lorsqu’une nouvelle fonction pourrait raisonnablement résider dans plusieurs couches. Rejetez les conceptions qui affaiblissent les paramètres sécurisés par défaut uniquement pour réduire l’effort d’implémentation. Prenez en compte la compatibilité avec tous les systèmes d’exploitation pris en charge dès la première décision de conception. ## Suivez le style habituel de Go pour les erreurs, les noms et les commentaires Utilisez des retours anticipés pour les erreurs et maintenez le chemin de réussite au niveau d’indentation le plus faible. Évitez les branches else après une branche qui effectue déjà un retour. Écrivez les sigles courants sous leur forme conventionnelle en majuscules, notamment URL, HTTP et ID. Choisissez des noms de récepteurs courts qui reflètent systématiquement le type du récepteur. Commencez les chaînes d’erreur par du texte en minuscules et omettez la ponctuation finale. Rédigez la documentation exportée sous forme de phrases complètes commençant par le nom déclaré. Utilisez une tranche nil lorsqu’une tranche vide allouée n’a aucune valeur sémantique. Renvoyez des erreurs pour les échecs attendus au lieu de déclencher un panic. Maintenez le traitement des erreurs près de l’opération susceptible d’échouer. N’enveloppez les erreurs que lorsque le contexte supplémentaire aide à localiser l’opération qui a échoué. Conservez les erreurs sous une forme que les appelants peuvent inspecter lorsqu’un traitement programmatique est prévu. Évitez les flux de contrôle ingénieux qui masquent la responsabilité ou le nettoyage des ressources. Exécutez le formatage et l’analyse statique avant la revue. Appliquez les conventions établies du dépôt même lorsqu’un autre style Go valide existe. Utilisez des assertions d’interface à la compilation pour les types censés satisfaire les interfaces du framework. Maintenez stables les noms des récepteurs, des paquets et des éléments exportés, sauf si une modification délibérée de compatibilité est approuvée. ## Construisez chaque module dans l’ordre, de la création au nettoyage Enregistrez chaque module au moyen du mécanisme d’enregistrement standard du framework. Renvoyez des métadonnées contenant un ID de module avec espace de noms et un constructeur pour une nouvelle instance. Préservez les constructeurs de tout effet secondaire propre à l’environnement. Considérez le cycle de vie comme des phases ordonnées : 1. Construisez une nouvelle valeur. 2. Décodez la configuration dans cette valeur. 3. Provisionnez les dépendances d’exécution. 4. Validez la configuration complète. 5. Servez ou exécutez la fonction du module. 6. Nettoyez les ressources dont il est responsable. N’effectuez pas la validation finale avant que les données de configuration et de provisionnement soient disponibles. Rendez le nettoyage sûr après un provisionnement partiel et des signaux d’arrêt répétés lorsque le framework peut l’appeler de cette façon. Utilisez des garde-fous à la compilation pour le provisionnement, la validation, l’analyse de la configuration et les autres interfaces facultatives. Séparez les responsabilités du cycle de vie afin que les erreurs de configuration puissent être distinguées des défaillances d’exécution. Renvoyez des erreurs exploitables lors du provisionnement et de la validation. Ne dissimulez pas un échec d’initialisation derrière un module partiellement utilisable. N’utilisez les interfaces d’application de premier niveau que pour les composants qui sont véritablement responsables du comportement de démarrage et d’arrêt. Maintenez les ID de modules stables, car la configuration, les adaptateurs et les intégrations externes peuvent en dépendre. ## Lisez strictement les fichiers de configuration et protégez les points de terminaison administratifs Analysez la configuration destinée aux utilisateurs avec le distributeur de jetons du framework ou un itérateur structuré équivalent. Consommez le nom de la directive avant de lire les arguments sur la même ligne. Traitez les arguments sur la même ligne séparément des blocs imbriqués. Relevez le niveau d’imbrication actuel et arrêtez-vous lorsque l’analyseur quitte ce bloc. Reconnaissez explicitement les sous-directives prises en charge. Validez immédiatement les arguments obligatoires et renvoyez l’erreur d’argument standard de l’analyseur. Rejetez les sous-directives inconnues avec une erreur qui inclut la valeur inattendue. Documentez la syntaxe acceptée près de l’analyseur comme un contrat maintenu. Maintenez la sortie de l’adaptateur alignée sur le modèle natif de configuration structurée. Obtenez les enregistreurs et les autres modules par l’intermédiaire du contexte du framework pendant le provisionnement. Utilisez un enregistreur structuré limité au module et ajoutez des champs au lieu de construire des messages non structurés. Ne stockez pas les contextes de requête ou de provisionnement dans des structures de longue durée. Implémentez l’interface de routage du framework lorsque vous ajoutez des points de terminaison administratifs. Appliquez les règles d’authentification, d’autorisation et d’exposition attendues par l’interface d’administration. Validez la configuration avant que le module commence à traiter le trafic. ## Évitez les nouvelles dépendances et gardez des limites claires entre paquets Évitez les nouvelles dépendances sauf si leur valeur dépasse clairement les coûts de maintenance, de sécurité et de chaîne d’approvisionnement. Intégrez directement les petites fonctions stables lorsqu’une dépendance minime ajouterait un risque disproportionné. N’exposez pas les types de paquets externes par l’intermédiaire de l’API publique du projet. Encapsulez le comportement des tiers derrière des interfaces et des types appartenant au projet. Utilisez les outils de modules du langage pour maintenir la cohérence des déclarations de dépendances et des sommes de contrôle. Exécutez la commande de rangement des dépendances et examinez son diff au lieu d’accepter des modifications sans rapport. Séparez les adaptateurs de configuration des modules d’exécution. Séparez les utilitaires de test des points d’entrée de production. Placez les modules standard dans le registre utilisé par la commande distribuée. N’importez pas de modules facultatifs dans l’exécutable par défaut sans décision produit explicite. Préservez les limites des paquets autour du traitement des protocoles, de la sécurité du transport et des opérations sur les certificats. Ne choisissez des abstractions généralisées qu’après avoir identifié le comportement répété auquel elles répondent. Rejetez les abstractions spéculatives qui masquent une implémentation simple. Lors d’une restructuration, préservez le comportement observable ou documentez et testez chaque modification intentionnelle. Examinez les paquets critiques pour la sécurité et les modifications de dépendances plus en profondeur que le code interne courant. ## Passez tous les tests, le lint et la compilation avant la fusion Considérez chaque porte de qualité obligatoire comme bloquante et non comme consultative. Exécutez la suite complète en mode short avec la détection des conditions de concurrence activée. Exécutez le linter configuré en lui accordant assez de temps pour parcourir l’intégralité du dépôt. Compilez tous les paquets pour détecter les interfaces manquantes, les contraintes de plateforme et les erreurs d’enregistrement. Pour les modifications de performances, exécutez des bancs d’essai avec des mesures de mémoire. Comparez les résultats des bancs d’essai à une référence appropriée et tenez compte de la variabilité. Exécutez des tests d’intégration ciblés pour le comportement de serveur affecté. Assurez-vous que les tests réussissent sous Linux, macOS et Windows lorsque l’intégration continue prend en charge ces plateformes. Examinez les avertissements dans les fichiers modifiés même si des avertissements sans rapport existent ailleurs. Ne marquez pas une pull request comme prête à fusionner tant qu’une porte obligatoire de test, de lint, de compilation ou de mesure des performances manque. Consignez les commandes et les résultats pertinents afin que les réviseurs puissent reproduire les preuves. Distinguez un échec de test d’un échec de l’environnement avant de modifier le code de production. Maintenez la vérification proportionnelle à la modification tout en couvrant chaque porte directement affectée. Réexécutez les portes affectées après toute modification de code effectuée en réponse à la revue. Traitez les rapports de conditions de concurrence et les défaillances intermittentes de simultanéité comme des défauts nécessitant une enquête. ## Écrivez des tests unitaires pilotés par table et des tests de serveur sur des ports dédiés Préférez les tests pilotés par table lorsque plusieurs entrées partagent le même comportement. Donnez à chaque cas une entrée explicite, une sortie attendue et un état d’erreur attendu. Vérifiez à la fois l’absence des erreurs attendues et les erreurs inattendues renvoyées. Ne comparez les valeurs renvoyées qu’après avoir traité correctement la condition d’erreur. Incluez des cas valides, invalides, limites et de régression. Nommez les cas lorsque les index seuls compliqueraient le diagnostic des défaillances. Maintenez les fixtures minimales et déterministes. Utilisez le banc d’essai de serveur du projet pour le comportement de configuration de bout en bout. Initialisez les serveurs de test avec une configuration isolée et des formats explicites. Utilisez des ports non standard pour éviter les conflits avec les services exécutés localement. Réservez des ports distincts pour l’administration, le trafic en clair et le trafic chiffré lorsque cela est nécessaire. Vérifiez l’état, le corps et les autres comportements observables de l’extérieur. Nettoyez les serveurs, les écouteurs, les fichiers et les goroutines créés par le test. Ne dépendez pas de l’ordre des tests ni d’un état global mutable partagé. Testez les erreurs d’analyse de la configuration ainsi que le démarrage réussi du serveur. Ajoutez des cas propres à la plateforme lorsque les chemins, les sockets, les signaux ou le comportement des processus diffèrent. Maintenez les tests d’intégration suffisamment ciblés pour qu’une défaillance désigne le contrat rompu. ## Laissez les pull requests, les rapports de sécurité et les accords à une personne Considérez les discussions de tickets, les pull requests, les accords de licence et les rapports de sécurité comme des actions externes régies par des personnes. Un assistant d’IA ne doit pas usurper l’identité d’un contributeur humain ni accepter un accord juridique au nom d’une personne. Ne créez ni ne soumettez de tickets externes, de pull requests ou de rapports de sécurité, sauf si la politique applicable autorise explicitement cette action de l’agent. Limitez l’assistance à la revue au rôle autorisé et indiquez la participation de l’IA lorsque cela est exigé. Ne dissimulez pas l’implication de l’IA lorsque la politique de contribution impose sa divulgation. Exigez que l’opérateur humain comprenne et puisse expliquer chaque ligne soumise. Testez le code assisté par IA au moyen de contrôles automatisés lorsque c’est possible, et par des contrôles manuels approfondis dans le cas contraire. Examinez le code généré pour détecter les éléments copiés, les licences incompatibles et les affirmations non vérifiées. N’inventez pas de détails sur des vulnérabilités et ne soumettez pas de rapport de sécurité non vérifié. L’assistance à la traduction ou à l’édition doit préserver les faits de sécurité vérifiés par l’auteur humain. Laissez les signatures, attestations et accords de contribution réservés aux personnes à la charge de la personne responsable. Lorsqu’une action demandée entre en conflit avec la politique de contribution, arrêtez cette action et expliquez la limite applicable. N’ajoutez pas de fichiers, de commentaires ou de commits trompeurs pour remplacer une action externe interdite. Préservez l’utilité technique du correctif sans contourner le processus de la communauté. Avant l’approbation, vérifiez séparément la divulgation, la compréhension, les tests et les licences. La responsabilité humaine reste obligatoire même lorsqu’un agent a produit la majeure partie de l’implémentation.