Thema: dependencies
-
PostgreSQL-Erweiterungen verwalten: installieren, versionieren, aktualisieren und dumpen
Eine Erweiterung bündelt SQL-Objekte und oft eine Shared Library unter einem Namen mit einer Control-Datei und versionierten Skripten; CREATE EXTENSION installiert sie je Datenbank, ALTER EXTENSION UPDATE wendet die Update-Skripte des Autors an, und pg_dump gibt nur die Zeile CREATE EXTENSION aus. Installierte Dateien, Katalogversion und geladene Bibliothek im Gleichschritt halten, besonders bei Paket-Upgrades und pg_upgrade.
-
Dependency Confusion: wenn ein öffentliches Paket ein privates verdrängt
Löst ein Build Paketnamen sowohl über einen privaten als auch einen öffentlichen Index auf, kann ein Angreifer, der den privaten Namen öffentlich mit einer höheren Version veröffentlicht, seinen eigenen Code installiert bekommen; die pip-Dokumentation nennt --extra-index-url für private Pakete deshalb ausdrücklich unsicher. Gegenmassnahmen sind an eine Registry gebundene Namensräume, ein einzelner proxyierender Index, Hash-Pinning und das Beanspruchen von Namen.
-
Cargo, Crates und Editions: wie ein Rust-Projekt gebaut und versioniert wird
Cargo baut ein Crate aus Cargo.toml, löst Abhängigkeiten mit SemVer-kompatiblen Bereichen in Cargo.lock auf und kann zwei inkompatible Hauptversionen desselben Crates in einem einzigen Build enthalten. Editions sind pro Crate wählbare Sprachversionen, die zusammenarbeiten, sodass das Anheben der Edition eines Crates dessen abhängige Crates nie zum Mitziehen zwingt.
-
Maven gegen Gradle: was Einsteiger brauchen, um das JVM-Projekt einer anderen Person zu bauen
Maven beschreibt ein Projekt deklarativ in pom.xml und durchläuft feste Lebenszyklusphasen (validate, compile, test, package, verify, install, deploy), an die Plugin-Goals gebunden sind; Gradle führt einen Graphen von Tasks aus, die durch build.gradle(.kts)-Skripte und Plugins konfiguriert werden. Beide lösen transitive Abhängigkeiten auf, aber mit unterschiedlichen Konfliktregeln (Maven: nächstgelegene Definition; Gradle: höchste Version), und beide liefern ein Wrapper-Skript, das die Version des Build-Tools festlegt.
-
Abhängigkeitshygiene und Prüfungen der Software-Lieferkette
Wissen, wovon man abhängt, es festpinnen und verifizieren, auf bekannte Schwachstellen achten und aus vertrauenswürdigen Quellen bauen; SLSA-Stufen, OpenSSF Scorecard und hash-geprüfte Installationen liefern konkrete Schritte.
-
Abhängigkeitsreihenfolge per Graphtraversierung: BFS, DFS und topologische Sortierung
Abhängigkeiten als gerichteten Graphen modellieren, mit Breiten- oder Tiefensuche alles finden, was von einer Änderung betroffen ist, und mit Kahns Algorithmus oder DFS-Nachordnung eine Build- oder Migrationsreihenfolge erzeugen, die Zyklen meldet statt sie zu verbergen; graphlib und tsort setzen die Sortierung um.
-
Software-Stücklisten mit SPDX und CycloneDX
Eine SBOM ist ein maschinenlesbares Inventar der Komponenten eines Software-Artefakts; SPDX und CycloneDX sind die beiden verbreiteten Formate, und pro Release eine SBOM zu erzeugen unterstützt Schwachstellenabgleich und Lizenzprüfung.
-
Rhythmus für Abhängigkeits-Updates: Batching, Gruppierung und was auf einmal gemergt wird
Update-Bots öffnen einen Pull Request pro Abhängigkeit, sofern nicht anders konfiguriert; ein tragfähiger Rhythmus merged Sicherheitsfixes, sobald sie eintreffen, bündelt Patch- und Minor-Updates zu einer geplanten Gruppe und behandelt Major-Versionen als geplante Arbeit. Dependabot und Renovate dokumentieren beide Scheduling und Gruppierung, und Renovates Leitfaden benennt die Kosten der Gruppierung: Eine fehlschlagende Gruppe blockiert alle ihre Mitglieder.
-
Software-Stücklisten (SBOM): das Inventar der eigenen Lieferkette
Eine Software-Stückliste zählt maschinenlesbar auf, welche Komponenten in welcher Version in einem gelieferten Artefakt stecken. SPDX (ISO/IEC 5962:2021) und CycloneDX (OWASP) sind die verbreiteten Formate; erzeugt wird sie pro Release aus dem gebauten Artefakt, daneben abgelegt und zum Abgleich mit Schwachstellenmeldungen und Lizenzpflichten genutzt. Zusammen mit Herkunftsnachweisen (SLSA) macht sie die Lieferkette prüfbar.
-
Welche Prüfungen bei automatisierten Dependency-Update-Pull-Requests haben eine bösartige oder defekte Version abgefangen, und welche erzeugen nur Störgeräusche?
Offene Frage: Automatisierte Update-Pull-Requests treffen täglich ein und werden oft bei grüner CI gemerged; die npm-Dokumentation beschreibt Provenance-Attestierungen, die sich mit npm audit signatures verifizieren lassen, doch welche Prüfungen (Provenance, Review des entpackten Diffs, Prüfung von Install-Skripten, Wartefristen, Lockfile-Diffs) haben nachweislich schon eine kompromittierte oder defekte Version abgefangen?
-
NuGet-Abhängigkeiten pinnen: PackageReference, zentrale Paketverwaltung und packages.lock.json
NuGet löst beim Restore die niedrigste zutreffende Version jedes Pakets auf, sodass ein Restore driften kann, wenn neue Versionen oder gleitende Bereiche auftauchen; ein wiederholbarer Build deklariert Versionen einmalig in Directory.Packages.props, aktiviert RestorePackagesWithLockFile, damit packages.lock.json den vollständigen Abschluss festhält, committet die Lock-Datei für Anwendungen und restored in CI mit --locked-mode.
-
Packaging a Python project with pyproject.toml
pyproject.toml declares build system, metadata and dependencies in one standard file (PEP 517/518/621); with it, any compliant tool can build, install and lock the project without setup.py.
-
Virtual environments: one interpreter state per project
A virtual environment is a private site-packages tied to an interpreter; creating one per project prevents version conflicts and makes the dependency set reproducible and disposable.
-
Reproducible builds and pinned dependencies
A build is reproducible when the same source and build environment produce bit-for-bit identical output; lockfiles with hashes, pinned base images and fixed timestamps are the practical steps toward it.
-
Go modules: go.mod, go.sum and the major version suffix
A Go module is a versioned tree of packages described by go.mod; the go command picks dependency versions with minimal version selection, verifies downloads against go.sum, and requires a /v2-style suffix in the module path for every major version above 1, so incompatible versions have different import paths.
-
Submodules, subtrees or vendoring: three ways to include another repository
A submodule records a pointer (gitlink) to a commit of another repository and needs extra commands from every user; git subtree copies the other project's files and optionally its history into a subdirectory that behaves like normal files; plain vendoring copies files and records the upstream version by hand. Choose by how often the dependency changes and who must be able to clone.
Maschinenlesbar: JSON