c806c8d8d4
Replace the project directory tree and PR integration/versioning sections with a new "Philosophie de développement" section covering the NASA Power of Ten rules and security-by-design principles.
3.2 KiB
3.2 KiB
DEV
Standards
On suit ces deux guides :
- GUIDE.md : conventions générales de rédaction et de structure
- REDACTION.md : règles de style, ton et formatage
Philosophie de développement
Power of Ten
Tout le code produit suit les principes du NASA Power of Ten :
- Flux de contrôle simples — pas de
goto, pas de récursion non bornée, pas de pointeurs de fonctions imbriqués. - Boucles bornées — toute boucle doit avoir une limite maximale d'itérations statiquement vérifiable.
- Pas d'allocation dynamique après l'initialisation — allouer les ressources en amont, libérer proprement.
- Fonctions courtes et ciblées — une fonction = une responsabilité, tient sur un écran.
- Densité d'assertions élevée — valider les préconditions, postconditions et invariants explicitement.
- Portée des données minimale — déclarer les variables au plus près de leur utilisation, limiter l'exposition.
- Vérification systématique des retours — chaque valeur de retour ou promesse rejetée doit être gérée.
- Préprocesseur minimal — éviter la magie implicite ; préférer la clarté à la concision.
- Limiter les pointeurs — une seule indirection par niveau ; pas d'aliasing caché.
- Warnings = erreurs — le linter et le compilateur doivent passer sans avertissement.
Sécurité
Chaque contribution doit intégrer la sécurité dès la conception (security by design) :
- Validation des entrées — toute donnée externe (utilisateur, API tierce, fichier) est considérée malveillante jusqu'à preuve du contraire. Valider côté serveur, jamais uniquement côté client.
- Moindre privilège — un module n'accède qu'aux ressources strictement nécessaires à sa fonction.
- Pas de secrets dans le code — tokens, clés API, mots de passe passent exclusivement par des variables d'environnement ou un gestionnaire de secrets.
- Dépendances auditées — lancer
npm auditavant chaque publication ; ne pas introduire de dépendance avec des vulnérabilités connues non corrigées. - Gestion des erreurs opaque — les messages d'erreur exposés à l'utilisateur ne révèlent pas de détails internes (stack trace, chemin de fichier, requête SQL…).
- Protection contre les injections — utiliser exclusivement des requêtes paramétrées ou des ORM éprouvés ; jamais de concaténation de chaînes SQL/shell.
- Authentification et sessions — tokens signés, durée de vie limitée, révocation possible, rotation des secrets régulière.
- En-têtes HTTP de sécurité —
Content-Security-Policy,X-Content-Type-Options,Strict-Transport-Securityconfigurés sur toutes les routes.
Publier le package
Le package @zen/core est publié sur le registre npm à https://git.hyko.cx.
1. Configurer l'authentification
Créer un token d'accès dans Gitea (Settings → Applications → Generate Token), puis l'enregistrer localement :
npm config set //git.hyko.cx/api/packages/zen/npm/:_authToken TOKEN
Remplacer TOKEN par le token généré.
2. Build et publish
npm publish