Sujet : dependencies
-
Syntaxe des plages de versions dans npm, Cargo, pip, Composer, Go modules, Maven, NuGet et Bundler
Les opérateurs caret et tilde n'ont pas le même sens partout, Go modules n'a aucune notion de plage, et un numéro de version seul est un minimum inclusif dans NuGet mais une simple suggestion souple dans Maven.
-
Gérer les extensions PostgreSQL : installation, gestion des versions, mise à jour et sauvegarde
Une extension regroupe des objets SQL, et souvent une bibliothèque partagée, sous un même nom avec un fichier de contrôle et des scripts versionnés ; CREATE EXTENSION l'installe par base de données, ALTER EXTENSION UPDATE applique les scripts de mise à jour de l'auteur, et pg_dump n'émet que la ligne CREATE EXTENSION. Il faut garder synchronisés les fichiers installés, la version du catalogue et la bibliothèque chargée, en particulier lors des mises à jour de paquets et de pg_upgrade.
-
CMake PUBLIC, PRIVATE et INTERFACE : corriger la portée des dépendances sans drapeaux globaux
Choisir la portée d'une dépendance à partir du contrat de la cible consommatrice et la vérifier avec un consommateur externe minimal.
-
Confusion de dépendances : quand un paquet public masque un paquet privé
Si une build résout les noms de paquets à la fois sur un index privé et un index public, une personne malveillante qui publie le nom privé en public avec une version supérieure peut faire installer son propre code ; la documentation de pip qualifie justement --extra-index-url pour des paquets privés de non sûr pour cette raison. Les défenses consistent en des espaces de noms liés à un seul registre, un index unique servant de proxy, l'épinglage par empreinte (hash) et la revendication des noms.
-
Cargo, crates et éditions : comment un projet Rust est construit et versionné
Cargo construit un crate à partir de Cargo.toml, résout les dépendances avec des plages compatibles SemVer dans Cargo.lock, et peut inclure deux versions majeures incompatibles d'un même crate dans une seule build. Les éditions sont des versions du langage par crate, à activation volontaire, qui restent interopérables : monter l'édition d'un crate n'oblige jamais ses dépendants à suivre.
-
Maven contre Gradle : ce qu'un nouvel arrivant doit savoir pour construire le projet JVM de quelqu'un d'autre
Maven décrit un projet de façon déclarative dans pom.xml et exécute des phases de cycle de vie fixes (validate, compile, test, package, verify, install, deploy) avec des objectifs de plugin qui s'y rattachent ; Gradle exécute un graphe de tâches configuré par des scripts build.gradle(.kts) et des plugins. Les deux résolvent les dépendances transitives mais avec des règles de conflit différentes (Maven : la définition la plus proche ; Gradle : la version la plus élevée), et les deux fournissent un script wrapper qui fixe la version de l'outil de build.
-
Hygiène des dépendances et vérifications de la chaîne d'approvisionnement logicielle
Savoir de quoi on dépend, figer et vérifier ces dépendances, surveiller les vulnérabilités connues et construire à partir de sources fiables ; les niveaux SLSA, l'OpenSSF Scorecard et les installations vérifiées par hachage fournissent des étapes concrètes.
-
Noms de paquets hallucinés et similaires : vérifier une dépendance avant qu'un agent ne l'installe
Les modèles générateurs de code nomment parfois des paquets qui n'existent pas ; un attaquant peut enregistrer un tel nom, et les typosquatteurs enregistrent des variantes proches de paquets populaires. Avant l'installation, un agent doit confirmer que le paquet existe, qu'il correspond bien au projet visé et qu'il n'a pas été récemment enregistré sous un nom prêtant à confusion.
-
Ordre des dépendances par parcours de graphe : BFS, DFS et tri topologique
Modéliser les dépendances comme un graphe orienté, utiliser un parcours en largeur ou en profondeur pour trouver tout ce qu'affecte un changement, et l'algorithme de Kahn ou l'ordre post-fixe du DFS pour produire un ordre de build ou de migration qui signale les cycles au lieu de les dissimuler ; graphlib et tsort implémentent le tri.
-
Vérifier l'identité d'un paquet suggéré avant de l'ajouter à un projet
Vérifier qu'un nom de paquet suggéré pendant le codage correspond bien à la dépendance maintenue visée, avant de modifier les fichiers de dépendances du projet ou d'exécuter des points d'ancrage d'installation.
-
Nomenclatures logicielles avec SPDX et CycloneDX
Une SBOM (nomenclature logicielle) est un inventaire exploitable par machine des composants d'un artefact logiciel ; SPDX et CycloneDX sont les deux formats largement utilisés, et en générer une par version facilite le rapprochement des vulnérabilités et la revue des licences.
-
Cadence de mise à jour des dépendances : regroupement par lots, groupage et ce qu'il faut fusionner ensemble
Les robots de mise à jour ouvrent une pull request par dépendance sauf configuration contraire ; une cadence durable fusionne les correctifs de sécurité dès leur arrivée, regroupe les mises à jour de correctif et mineures dans un lot planifié, et traite les versions majeures comme un travail planifié. Dependabot et Renovate documentent tous deux la planification et le groupage, et le guide de Renovate nomme le coût du groupage : un groupe qui échoue bloque tous ses membres.
-
npm « ERESOLVE unable to resolve dependency tree » et conflits de dépendances peer
Depuis npm 7, les peerDependencies sont installées automatiquement ; une version qui ne peut pas satisfaire toutes les plages peer à la fois provoque l'erreur « npm error code ERESOLVE » (« npm ERR! code ERESOLVE » avant npm 10.6). L'article explique comment lire les lignes Found/Could not resolve affichées par npm lui-même pour identifier précisément les paquets en conflit, et pourquoi --legacy-peer-deps ou --force ne doivent pas être la réponse par défaut.
-
Nomenclatures logicielles (SBOM) : l'inventaire de sa propre chaîne d'approvisionnement
Une nomenclature logicielle énumère de façon lisible par machine quels composants, dans quelle version, entrent dans un artefact livré. SPDX (ISO/IEC 5962:2021) et CycloneDX (OWASP) sont les formats répandus ; elle est produite à chaque publication à partir de l'artefact construit, conservée à ses côtés, et utilisée pour la confronter aux signalements de vulnérabilités et aux obligations de licence. Associée aux preuves de provenance (SLSA), elle rend la chaîne d'approvisionnement vérifiable.
-
Quels contrôles sur les pull requests automatisées de mise à jour des dépendances ont détecté une version malveillante ou défaillante, et lesquels ne font qu'ajouter du bruit ?
Question ouverte : les pull requests de mise à jour automatisée arrivent quotidiennement et sont souvent fusionnées sur la base d'une CI verte ; la documentation npm décrit des attestations de provenance que npm audit signatures peut vérifier, mais quels contrôles (provenance, revue du diff décompressé, inspection des scripts d'installation, périodes d'attente, diffs de lockfile) ont un historique de détection d'une version compromise ou défaillante ?
-
Figer les dépendances NuGet : PackageReference, gestion centralisée des paquets et packages.lock.json
NuGet résout la version applicable la plus basse de chaque paquet au moment de la restauration, si bien qu'une restauration peut dériver quand de nouvelles versions ou des plages flottantes apparaissent ; une build reproductible déclare les versions une seule fois dans Directory.Packages.props, active RestorePackagesWithLockFile pour que packages.lock.json enregistre la fermeture transitive complète, versionne le fichier de verrouillage pour les applications, et restaure avec --locked-mode en intégration continue.
-
Empaqueter un projet Python avec pyproject.toml
pyproject.toml déclare le système de build, les métadonnées et les dépendances dans un unique fichier standard (PEP 517/518/621) ; grâce à lui, tout outil conforme peut construire, installer et figer le projet sans setup.py.
-
Environnements virtuels : un état d'interpréteur par projet
Un environnement virtuel est un site-packages privé lié à un interpréteur ; en créer un par projet évite les conflits de versions et rend l'ensemble des dépendances reproductible et jetable.
-
Builds reproductibles et dépendances figées
Un build est reproductible lorsque la même source et le même environnement de build produisent une sortie identique bit à bit ; des fichiers de verrouillage (lockfiles) avec empreintes, des images de base figées et des horodatages fixes en sont les étapes pratiques.
-
Modules Go : go.mod, go.sum et le suffixe de version majeure
Un module Go est une arborescence versionnée de paquets décrite par go.mod ; la commande go choisit les versions de dépendances par sélection de version minimale, vérifie les téléchargements par rapport à go.sum, et exige un suffixe du type /v2 dans le chemin du module pour chaque version majeure supérieure à 1, de sorte que les versions incompatibles aient des chemins d'import différents.
Lisible par machine : JSON