Aller au contenu

08. Répertoire des Solutions d'Ingénierie Système Validées

Navigation : Documentation > 08. Solutions d'Ingénierie Système
Sécurité & Vulnérabilités : L'analyse complète des CVEs et leurs mitigations architecturales sont centralisées dans CVEs & Mitigations Comparatives.

Sommaire

  1. Système de Fichiers, Routage & Stockage
  2. 1.1 Verrouillage sous Windows (Rename-to-Trash)
  3. 1.2 Intégration Graphique Multiplateforme
  4. 1.3 Suppression Mark of the Web (MotW)
  5. 1.4 Contournement MAX_PATH
  6. 1.5 Permissions POSIX chmod +x
  7. 1.6 Archives Avancées (.zst, .7z)
  8. 1.7 Déduplication CoW & Reflinks
  9. 1.8 Scripts Compagnons (npm, pip)
  10. Cycle de Vie, Dépendances, Concurrence & Performance
  11. 2.1 Concurrence Inter-Processus et Verrou Global (.lock)
  12. 2.2 Gestion Légère des Dépendances Runtimes
  13. 2.3 Compatibilité Glibc vs Musl sous Linux
  14. 2.4 Gestion des Versions : Rollback Instantané et Garbage Collector
  15. 2.5 Maintenance Automatisée des Manifestes (Autoupdate Bot)
  16. 2.6 Persistance et Propagation du $PATH entre Shells
  17. 2.7 Dépendances Cachées C/C++ (VCRUNTIME140.dll et libstdc++)
  18. 2.8 Atténuation de la Latence de Cold Start Nushell
  19. Réseau, Antivirus & Écosystème Entreprise
  20. 3.1 Sécurité de la Distribution (Signature Cryptographique Ed25519)
  21. 3.2 Proxies d'Entreprise et Certificats PKI Privés
  22. 3.3 Variables d'Environnement Permanentes Gérées Atomiquement
  23. 3.4 Collisions de Noms dans bin/ et Arbitrage d'Alternatives
  24. 3.5 Immunité contre le Rate-Limiting GitHub API
  25. 3.6 Prévention des Ruptures de Version Nushell
  26. 3.7 Bootstrap Hybride en Environnement Durci
  27. 3.8 Détection Proactive de la Quarantaine Antivirus
  28. 3.9 Politiques WDAC et Re-Signature de Code Authenticode
  29. 3.10 Protection contre le Gel et le Rejeu d'Index (TUF)
  30. 3.11 Remplacement Strictement Atomique des Pointeurs (.target)
  31. 3.12 Isolation Stricte des Permissions Multi-Utilisateurs

1. Système de Fichiers, Routage & Stockage

1.1 Verrouillage de Fichiers sous Windows (File Locking)

  • Mécanisme (safe_replace) : La stratégie Rename-to-Trash déplace le fichier actif vers ~/.erable/trash/<nom>.<uuid>.old puis installe la nouvelle version. La purge de trash/ est différée au redémarrage ou via erable cleanup.

1.2 Intégration Graphique Multiplateforme

  • Mécanisme : Le module parts/shortcuts.toml génère automatiquement un raccourci .lnk dans le Menu Démarrer Windows (via COM WScript), un fichier .desktop dans ~/.local/share/applications/ sous Linux, ou un lanceur dans ~/Applications/ sous macOS.

1.3 Suppression du "Mark of the Web" (MotW) sous Windows

  • Mécanisme (clean_motw) : Le moteur supprime systématiquement le flux NTFS Zone.Identifier dès l'extraction via Unblock-File pour neutraliser les blocages Windows SmartScreen sur les binaires téléchargés.

1.4 Contournement de la Limite MAX_PATH (260 caractères)

  • Mécanisme (normalize_path) : Le moteur préfixe systématiquement tous les chemins absolus Windows par le préfixe NT étendu \\?\, étendant la limite à 32 767 caractères.

1.5 Garantie des Permissions d'Exécution POSIX (chmod +x)

  • Mécanisme (ensure_executable) : Immédiatement après extraction, le moteur applique explicitement chmod +x sur tous les fichiers répertoriés dans targets.binaries sous Linux et macOS.

1.6 Support des Formats d'Archives Avancés (.zst, .7z)

  • Mécanisme (lib/archive.nu) : Extraction native pour zip/tar.gz, détection de l'outil système pour zstd/7z, et repli automatique en téléchargeant un helper statique autonome (7za) dans ~/.erable/core/tools/.
  • Mécanisme : Lors des mises à jour applicatives (rétention N-1 pour le rollback instantané en $\mathcal{O}(1)$), le moteur partage les blocs physiques pour éviter toute duplication inutile :
  • Linux : cp --reflink=auto / ioctl(FICLONE) sur systèmes Btrfs, XFS et ZFS, garantissant un clonage d'extents physiques à coût disque nul (0 octet physique additionnel).
  • macOS : Appel de la primitive noyau APFS clonefile(), créant des clones instantanés pointant vers les mêmes blocs physiques.
  • Windows : Clonage d'extents de blocs sur ReFS (FSCTL_DUPLICATE_EXTENTS_TO_FILE) et Hardlinks NTFS immuables (CreateHardLinkW) pour les fichiers strictement identiques. L'immutabilité absolue des répertoires packages/<pkg>/<version>/ garantit l'absence totale d'effets de bord collatéraux.

1.8 Résolution des Outils à Scripts Compagnons (npm, pip) par Trampolines

  • Mécanisme : Les Trampolines Universels initialisent le répertoire de travail courant sur le dossier réel du binaire cible avant l'appel (lpCurrentDirectory ou cd), garantissant que %~dp0 résout les dépendances relatives locales (node_modules/npm).

2. Cycle de Vie, Dépendances, Concurrence & Performance

2.1 Concurrence Inter-Processus et Verrou Global (.lock)

  • Mécanisme (lib/lock.nu) : Acquisition obligatoire d'un verrou exclusif sur ~/.erable/.lock avant toute opération de mutation (LockFileEx sous Windows, flock(LOCK_EX) sous Unix).

2.2 Gestion Légère des Dépendances Runtimes

  • Mécanisme : Résolution linéaire ordonnée via la directive depends_on = [...] dans parts/package.toml installant les dépendances manquantes avant la cible.

2.3 Compatibilité Glibc vs Musl sous Linux

  • Mécanisme : Priorité absolue donnée aux cibles compilées en statique musl (x86_64-unknown-linux-musl) dans parts/targets.toml, et contrôle pré-vol via ldd.

2.4 Gestion des Versions : Rollback Instantané et Garbage Collector

  • Mécanisme :
  • erable rollback <package> : Restauration instantanée du fichier .target vers la version précédente en $\mathcal{O}(1)$.
  • erable cleanup [--keep N] : Purge des versions orphelines non actives au-delà des $N$ versions de rétention.

2.5 Maintenance Automatisée des Manifestes (Autoupdate Bot)

  • Mécanisme : Un workflow GitLab CI programmé lit parts/autoupdate.toml, détecte les releases amont, calcule les hashes SHA-256 et publie la mise à jour sans intervention humaine.

2.6 Persistance et Propagation du $PATH entre Shells Hôtes

  • Mécanisme : Mise à jour immédiate en mémoire de $env.PATH dans la session Nushell courante, et commande dédiée erable setup-shell [bash|zsh|nu|pwsh] pour les dotfiles.

2.7 Dépendances Cachées C/C++ (VCRUNTIME140.dll et libstdc++)

  • Mécanisme : Inspection statique des imports PE/ELF en CI (dumpbin /imports), injection de depends_on = ["vcredist-2022"] dans le manifest, et appel de SetErrorMode dans le pilote Win32.

2.8 Atténuation de la Latence de "Cold Start" de Nushell (< 8ms)

  • Mécanisme : Invocations internes systématiques en mode hermétique isolé : nu --no-config-file --no-history -c "...".

3. Réseau, Antivirus & Écosystème Entreprise

3.1 Sécurité de la Distribution (Signature Cryptographique Ed25519)

  • Mécanisme : Signature obligatoire de index.nuon par une clé cryptographique officielle Ed25519 (index.nuon.sig), vérifiée localement avant toute action par le moteur client.

3.2 Proxies d'Entreprise et Certificats PKI Privés (TLS MITM)

  • Mécanisme (lib/network.nu) : Binaire nu compilé avec native-tls (CryptoAPI Windows / macOS Keychain), respect de HTTP_PROXY, HTTPS_PROXY, NO_PROXY, et support de $env.SSL_CERT_FILE et $env.erable_CA_BUNDLE.

3.3 Variables d'Environnement Permanentes (JAVA_HOME) Gérées Atomiquement

  • Mécanisme (parts/environment.toml) : Module déclaratif géré par lib/env_manager.nu qui injecte et retire proprement les variables du registre Windows (HKCU\Environment) ou des dotfiles Linux/macOS de manière atomique et réversible.

3.4 Collisions de Noms dans bin/ et Arbitrage d'Alternatives

  • Mécanisme (lib/collision.nu) : Détection préventive bloquant l'écrasement silencieux, drapeau d'alias à la volée (erable install fd-find --rename fd=fdfind), et gestionnaire d'alternatives interactif erable select <alias> <package>.

3.5 Immunité contre le Rate-Limiting GitHub API (Anti-403)

  • Mécanisme : Les clients consomment exclusivement les endpoints CDN statiques Raw sans toucher à l'API REST ; le bot CI d'autoupdate s'authentifie via GITHUB_TOKEN et scrape les flux RSS releases.atom illimités.

3.6 Prévention des Ruptures de Compatibilité Nushell (min_nu_version)

  • Mécanisme : Pragma déclaratif min_nu_version = "0.95.0" dans parts/package.toml vérifié au chargement du paquet, et incitation au déclaratif pur TOML.

3.7 Bootstrap Hybride en Environnement Durci (ConstrainedLanguageMode)

  • Mécanisme : Détection du mode de langage avec basculement vers MSI officiel sous Windows ; fourniture d'un binaire autonome erable-bootstrap compilé en statique Rust/musl sous Linux.

3.8 Détection Proactive de la Quarantaine Antivirus Silencieuse (AV Poisoning)

  • Mécanisme : Contrôle d'existence post-installation affichant une alerte explicite à l'utilisateur ("Binaire introuvable : vérifiez la quarantaine Windows Defender"), et scan préventif VirusTotal en CI.

3.9 Politiques WDAC et Re-Signature de Code Authenticode Locale

  • Mécanisme : Pipeline de re-signature locale post-extraction via signtool.exe exploitant le certificat interne d'entreprise ($env.erable_ENTERPRISE_SIGNING), ou enregistrement de catalogues de sécurité signés (.cat).

3.10 Protection contre le Gel et le Rejeu d'Index (Spécification TUF)

  • Mécanisme : Signature Ed25519 d'un en-tête index.nuon incluant un sequence_id strictement incrémental et une date d'expiration signée valid_until (max 7 jours).

3.11 Remplacement Strictement Atomique des Fichiers Pointeurs (.target)

  • Mécanisme : Élimination de toute course critique de lecture par écriture temporaire <alias>.target.tmp.<pid>, FlushFileBuffers et substitution atomique via ReplaceFileW (Windows) ou rename() (POSIX).

3.12 Isolation Stricte des Permissions Multi-Utilisateurs

  • Mécanisme : Application automatique d'un chmod 0700 sous POSIX et d'ACLs Windows restreintes au SID du propriétaire sans héritage sur l'arborescence racine ~/.erable.

3.13 Libération des Alias Naturels pour l'Utilisateur Final et Isolation Conditionnelle du Runner CI

  • Problématique : Les utilisateurs finaux installant des distributions et suites logicielles (ex. anaconda3, winpython, git-with-openssh) s'attendent à utiliser directement les commandes et alias naturels de leurs outils (python, pythonw, git, ssh) sans préfixe artificiel encombrant (anaconda3-python, winpython-python, git-with-openssh-git). Toutefois, lors des tests en intégration continue (CI), l'injection indiscriminée de ces alias dans la variable d'environnement PATH du runner risquerait de substituer les exécutables système du runner (comme le Python ou le Git système utilisé par GitLab CI).
  • Mécanisme de Résolution Robuste & Conditionnel :
  • Expérience Utilisateur 100% Naturelle (Sans Préfixe) : Les manifestes de paquets (parts/targets.toml) conservent les alias authentiques (python, pythonw, git, ssh, pwsh). Les utilisateurs finaux bénéficient ainsi immédiatement des commandes usuelles dès l'installation du paquet.
  • Mode Standard Naturel par Défaut (99% des paquets) : Pour tous les paquets standards ne rentrant pas en collision avec des alias sensibles, le runner CI continue d'injecter .erable/bin dans env["PATH"], validant en conditions réelles la résolution standard des commandes dans l'environnement.
  • Mode Isolation Hermétique Conditionnel (Paquets en Collision) : Uniquement lorsqu'un paquet déclare un alias système sensible (python, git, ssh, bash, sh, pwsh, etc.) :
    • La variable PATH du runner est laissée strictement intacte (protection absolue contre toute substitution d'outil du runner).
    • Les tests de cycle de vie (check_cmd, check_version, check_help, test direct) s'exécutent exclusivement par chemin d'accès absolu direct (resolve_command_binary), ciblant le binaire installé dans .erable/bin/<binary> sans passer par la recherche dans le PATH.
  • Sanctuarisation des Commandes Système Critiques : La liste CRITICAL_SYSTEM_RESERVED_NAMES (cmd, powershell.exe, login, rundll32, system32, erable, sudo, su) demeure strictement interdite afin d'empêcher tout détournement de l'OS. Les outils d'écosystème usuels (python, git, ssh, pwsh, cargo, curl, wget, tar, zip) sont en revanche pleinement autorisés comme alias d'applications légitimes.

3.14 Rigueur TLS X.509 et Gestion des Artefacts Non-Binaires

  • Problématique : L'ingestion automatisée rencontre parfois des serveurs amont avec des certificats auto-signés ou des chaînes incomplètes, ainsi que des paquets Scoop qui ne sont pas de véritables binaires portables (plugins .dll/.plgx, scripts purs .ps1/.sh).
  • Mécanisme de Résolution Robuste & Sans Complexité Inutile :
  • Zéro Affaiblissement Cryptographique (Pas de contournement SSL) : Le moteur CI Érable n'utilise aucun contournement de type _create_unverified_context. Tout paquet dont le serveur amont ne dispose pas d'une chaîne TLS X.509 valide n'est admis que si un miroir officiel ou une release HTTPS sécurisée (ex. CDN de l'éditeur, GitHub Releases certifié) est identifiable. À défaut, le paquet est classé en skipped (dead_or_invalid_tls_upstream).
  • Exclusion Propre des Plugins et Scripts Purs : Érable exige la présence d'exécutables binaires portables vérifiables. Les extensions d'applications tierces ne disposant d'aucun lanceur autonome (ex. plugins KeePass .plgx/.dll, plugins 7-Zip .dll, scripts PowerShell/Batch purs sans binaire) sont classées de manière déterministe en skipped (non_binary_plugin_or_script), évitant toute complexification du validateur binaire CI.

4. Liens et Références Associées