Tema: dependencies
-
Sintaxis de rangos de versiones en npm, Cargo, pip, Composer, módulos de Go, Maven, NuGet y Bundler
Los operadores caret y tilde no significan lo mismo en todos los ecosistemas, los módulos de Go no tienen rangos y un número de versión sin operadores es un mínimo inclusivo en NuGet, pero solo una sugerencia flexible en Maven.
-
Gestión de extensiones de PostgreSQL: instalación, versionado, actualización y volcado
Una extensión empaqueta objetos SQL y, a menudo, una biblioteca compartida bajo un único nombre, con un archivo de control y scripts versionados; CREATE EXTENSION la instala por base de datos, ALTER EXTENSION UPDATE aplica los scripts de actualización de quien la desarrolla, y pg_dump solo emite la línea CREATE EXTENSION. Es necesario mantener sincronizados los archivos instalados, la versión del catálogo y la biblioteca cargada, especialmente entre actualizaciones de paquetes y con pg_upgrade.
-
CMake PUBLIC, PRIVATE e INTERFACE: corregir el alcance de las dependencias sin usar flags globales
Elegir el alcance de una dependencia a partir del contrato del target que la consume, y verificarlo con un consumidor externo mínimo.
-
Confusión de dependencias: cuando un paquete público eclipsa a uno privado
Si una compilación resuelve los nombres de paquete a la vez en un índice privado y en uno público, un atacante que publique el nombre privado en público con una versión superior puede conseguir que se instale su código; la documentación de pip califica de insegura la opción --extra-index-url para paquetes privados precisamente por esta razón. Las defensas son espacios de nombres vinculados a un único registro, un índice único que actúa de proxy, la fijación por hash y la reserva de nombres.
-
Cargo, crates y ediciones: cómo se compila y se versiona un proyecto Rust
Cargo compila un crate a partir de Cargo.toml, resuelve las dependencias con rangos compatibles con SemVer en Cargo.lock, y puede incluir dos versiones mayores incompatibles de un mismo crate en una sola compilación. Las ediciones son versiones del lenguaje por crate, opcionales, que interoperan entre sí, así que actualizar la edición de un crate nunca obliga a sus dependientes a seguirlo.
-
Maven frente a Gradle: qué necesita quien se inicia para compilar el proyecto JVM de otra persona
Maven describe un proyecto de forma declarativa en pom.xml y ejecuta fases de ciclo de vida fijas (validate, compile, test, package, verify, install, deploy) con objetivos de plugin vinculados a ellas; Gradle ejecuta un grafo de tareas configurado mediante scripts build.gradle(.kts) y plugins. Ambos resuelven dependencias transitivas, pero con reglas de conflicto distintas (Maven: la definición más cercana; Gradle: la versión más alta), y ambos incluyen un script wrapper que fija la versión de la herramienta de compilación.
-
Higiene de dependencias y comprobaciones de la cadena de suministro de software
Conocer aquello de lo que se depende, fijarlo y verificarlo, vigilar las vulnerabilidades conocidas, y compilar a partir de fuentes de confianza; los niveles de SLSA, OpenSSF Scorecard y las instalaciones verificadas por hash ofrecen pasos concretos.
-
Nombres de paquetes alucinados y de aspecto similar: comprobar una dependencia antes de que un agente la instale
Los modelos generadores de código a veces nombran paquetes que no existen; un atacante puede registrar ese nombre, y quienes practican el typosquatting registran variantes muy próximas a las de paquetes populares. Antes de instalar, un agente debe confirmar que el paquete existe, que es el proyecto previsto y que no se registró recientemente bajo un nombre confundible.
-
Orden de dependencias mediante recorrido de grafos: BFS, DFS y ordenamiento topológico
Modelar las dependencias como un grafo dirigido, usar un recorrido en anchura o en profundidad para encontrar todo lo afectado por un cambio, y el algoritmo de Kahn o el posorden de DFS para producir un orden de compilación o migración que reporte los ciclos en lugar de ocultarlos; graphlib y tsort implementan el ordenamiento.
-
Comprobar la identidad de un paquete sugerido antes de añadirlo a un proyecto
Verificar que el nombre de un paquete sugerido durante la codificación corresponda a la dependencia mantenida prevista, antes de modificar los archivos de dependencias del proyecto o de ejecutar los scripts de instalación.
-
Listas de materiales de software con SPDX y CycloneDX
Un SBOM es un inventario legible por máquina de los componentes de un artefacto de software; SPDX y CycloneDX son los dos formatos de uso extendido, y generar uno por cada versión respalda la coincidencia de vulnerabilidades y la revisión de licencias.
-
Cadencia de actualización de dependencias: agrupación, lotes y qué fusionar de una vez
Los bots de actualización abren una pull request por dependencia salvo que se configure otra cosa; una cadencia sostenible fusiona las correcciones de seguridad en cuanto llegan, agrupa las actualizaciones de parche y menores en un lote programado, y trata las versiones mayores como trabajo planificado. Dependabot y Renovate documentan ambos la programación y la agrupación, y la guía de Renovate señala el coste de agrupar: un lote que falla bloquea a todos sus miembros.
-
«ERESOLVE unable to resolve dependency tree» de npm y los conflictos de peer dependencies
Desde npm 7, las peerDependencies se instalan automáticamente, y si ninguna versión puede satisfacer a la vez todos los rangos de peers, la instalación falla con 'npm error code ERESOLVE' ('npm ERR! code ERESOLVE' antes de npm 10.6). El artículo explica cómo leer las líneas Found/Could not resolve de npm para identificar los paquetes exactos en conflicto, y por qué --legacy-peer-deps o --force no deberían ser la respuesta por defecto.
-
Listas de materiales de software (SBOM): el inventario de la propia cadena de suministro
Una lista de materiales de software enumera de forma legible por máquina qué componentes, en qué versión, forman parte de un artefacto entregado. SPDX (ISO/IEC 5962:2021) y CycloneDX (OWASP) son los formatos más extendidos; se genera por versión a partir del artefacto compilado, se guarda junto a él y se usa para contrastarla con los avisos de vulnerabilidades y las obligaciones de licencia. Junto con las pruebas de procedencia (SLSA), hace verificable la cadena de suministro.
-
¿Qué comprobaciones en los pull requests de actualización automática de dependencias han detectado una versión maliciosa o defectuosa, y cuáles solo generan ruido?
Pregunta abierta: los pull requests de actualización automática llegan a diario y suelen fusionarse cuando el CI está en verde; la documentación de npm describe attestations de procedencia que npm audit signatures puede verificar, pero ¿qué comprobaciones (procedencia, revisión del diff del paquete descomprimido, inspección de scripts de instalación, periodos de espera, diffs del lockfile) han demostrado detectar una versión comprometida o defectuosa?
-
Fijar dependencias de NuGet: PackageReference, gestión central de paquetes y packages.lock.json
NuGet resuelve en cada restore la versión mínima aplicable de cada paquete, de modo que el resultado puede variar si aparecen versiones nuevas o rangos flotantes. Para un build repetible, se declaran las versiones una sola vez en Directory.Packages.props, se activa RestorePackagesWithLockFile para que packages.lock.json registre la clausura completa, se hace commit del archivo de bloqueo en las aplicaciones y se restaura con --locked-mode en CI.
-
Empaquetar un proyecto de Python con pyproject.toml
pyproject.toml declara en un único archivo estándar el sistema de compilación, los metadatos y las dependencias (PEP 517/518/621); con él, cualquier herramienta compatible puede compilar, instalar y bloquear las dependencias del proyecto sin necesidad de setup.py.
-
Entornos virtuales: un estado del intérprete por proyecto
Un entorno virtual es un site-packages privado asociado a un intérprete; crear uno por proyecto evita conflictos de versiones y hace que el conjunto de dependencias sea reproducible y desechable.
-
Compilaciones reproducibles y dependencias fijadas
Una compilación es reproducible cuando el mismo código fuente y el mismo entorno de compilación producen una salida idéntica bit a bit; los lockfiles con hashes, las imágenes base fijadas y las marcas de tiempo fijas son los pasos prácticos para lograrlo.
-
Módulos de Go: go.mod, go.sum y el sufijo de versión mayor
Un módulo de Go es un árbol versionado de paquetes descrito por go.mod; el comando go elige las versiones de las dependencias mediante selección de versión mínima, verifica las descargas con go.sum y exige un sufijo del tipo /v2 en la ruta del módulo para toda versión mayor superior a 1, de modo que las versiones incompatibles tengan rutas de importación distintas.
Legible por máquina: JSON