hykocx
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.
62 lines
3.2 KiB
Markdown
62 lines
3.2 KiB
Markdown
# DEV
|
|
|
|
## Standards
|
|
|
|
On suit ces deux guides :
|
|
|
|
- [GUIDE.md](./dev/GUIDE.md) : conventions générales de rédaction et de structure
|
|
- [REDACTION.md](./dev/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](https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code) :
|
|
|
|
1. **Flux de contrôle simples** — pas de `goto`, pas de récursion non bornée, pas de pointeurs de fonctions imbriqués.
|
|
2. **Boucles bornées** — toute boucle doit avoir une limite maximale d'itérations statiquement vérifiable.
|
|
3. **Pas d'allocation dynamique après l'initialisation** — allouer les ressources en amont, libérer proprement.
|
|
4. **Fonctions courtes et ciblées** — une fonction = une responsabilité, tient sur un écran.
|
|
5. **Densité d'assertions élevée** — valider les préconditions, postconditions et invariants explicitement.
|
|
6. **Portée des données minimale** — déclarer les variables au plus près de leur utilisation, limiter l'exposition.
|
|
7. **Vérification systématique des retours** — chaque valeur de retour ou promesse rejetée doit être gérée.
|
|
8. **Préprocesseur minimal** — éviter la magie implicite ; préférer la clarté à la concision.
|
|
9. **Limiter les pointeurs** — une seule indirection par niveau ; pas d'aliasing caché.
|
|
10. **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 audit` avant 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-Security` configuré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 :
|
|
|
|
```bash
|
|
npm config set //git.hyko.cx/api/packages/zen/npm/:_authToken TOKEN
|
|
```
|
|
|
|
Remplacer `TOKEN` par le token généré.
|
|
|
|
### 2. Build et publish
|
|
|
|
```bash
|
|
npm publish
|
|
``` |