Unix-Systeme verteilen Software über zentrale Paketquellen (Repositories). Ein Repository ist ein Server mit tausenden Paketen - Programme, Bibliotheken, Entwickler-Tools. Die Paketverwaltung lädt Paketlisten herunter, sucht installierbare Software und überprüft die Authentizität über kryptographische Signaturen.
Debian hat über 60.000 Pakete in seinen Repositories, Arch etwa 13.000 im Core-Repository plus tausende im AUR. OpenBSD liefert etwa 11.000 Pakete. Diese Zahlen zeigen den Umfang moderner Paketquellen - fast jede benötigte Software ist bereits paketiert und getestet verfügbar.
Zentrale vs. dezentrale Paketverteilung
Windows-Nutzer laden Software von verschiedenen Webseiten. Jeder Hersteller hostet seine eigenen Downloads. Diese Dezentralisierung erschwert Updates - jedes Programm braucht einen eigenen Update-Mechanismus. Sicherheitsprüfung liegt beim Nutzer.
Unix-Repositories zentralisieren die Softwareverteilung. Eine kleine Gruppe von Paket-Maintainern prüft, baut und signiert alle Pakete. Updates laufen über ein einziges System. Ein apt update && apt upgrade auf Debian aktualisiert das komplette System - Kernel, Programme, Bibliotheken.
Diese Zentralisierung hat Nachteile: Software muss geprüft und paketiert werden, bevor sie verfügbar ist. Proprietäre oder experimentelle Software findet sich selten in offiziellen Repositories. Der Vorteil überwiegt: Vertrauenswürdige, getestete, sichere Software aus einer Quelle.
Repository-Struktur und Organisation
Repositories sind hierarchisch organisiert. Debian trennt nach Lizenz-Status: main (freie Software), contrib (freie Software mit unfreien Abhängigkeiten), non-free (proprietäre Software). Innerhalb dieser Bereiche gibt es Kategorien: admin, net, devel, games.
Arch strukturiert nach Stabilität: core (essenzielle Basis-Pakete), extra (zusätzliche offizielle Pakete), multilib (32-Bit-Bibliotheken auf 64-Bit-Systemen). Das Arch User Repository (AUR) ist community-gepflegt, nicht offiziell geprüft.
OpenBSD unterscheidet Base-System (wird mit dem OS ausgeliefert) und Packages (aus Repositories). Packages werden nach Kategorie sortiert: databases/, www/, editors/. Die Struktur spiegelt sich in den Verzeichnissen unter /usr/local/ wider.
Jedes Repository enthält Metadaten-Dateien. Diese beschreiben verfügbare Pakete mit Name, Version, Abhängigkeiten, Größe, Beschreibung. Die Paketverwaltung lädt diese Metadaten-Listen herunter - erst dann weiß sie, welche Software installierbar ist.
Mirrors und Lastverteilung
Repositories werden weltweit gespiegelt (Mirror-Server). Ein Debian-Mirror in Deutschland hostet die identischen Pakete wie ein Mirror in Japan. Mirrors reduzieren Netzwerk-Last und beschleunigen Downloads - Nutzer laden von geografisch nahen Servern.
Mirror-Server synchronisieren mehrmals täglich mit dem Master-Repository. Neue Pakete oder Updates erscheinen auf dem Master, Mirrors ziehen diese Änderungen automatisch. Die Synchronisation erfolgt über rsync oder spezielle Mirror-Protokolle.
Manche Distributionen wählen automatisch den besten Mirror. Debian-Nutzer können httpredir.debian.org verwenden - ein CDN-System, das Anfragen an nahe Mirrors umleitet. Arch-Nutzer sortieren Mirror-Listen mit reflector nach Geschwindigkeit und Aktualität.
Mirror-Ausfälle sind unkritisch - die Paketverwaltung probiert den nächsten Mirror. Eine Liste von 10-20 Mirrors garantiert Verfügbarkeit. Nutzer können Mirrors manuell wechseln, falls der aktuelle langsam oder veraltet ist.
GPG-Signaturen und Authentizität
Jedes Paket trägt eine kryptographische Signatur. Die Distribution signiert Pakete mit einem privaten GPG-Schlüssel. Der zugehörige öffentliche Schlüssel ist auf dem System installiert. Die Paketverwaltung prüft bei Installation: Stimmt die Signatur?
Ein manipuliertes Paket hat eine ungültige Signatur. Ein Man-in-the-Middle-Angreifer kann gefälschte Pakete einspeisen - die Signatur-Prüfung schlägt fehl, Installation wird verweigert. Diese Kette vom Paket-Maintainer zum Nutzer-System sichert die Software-Herkunft.
Die öffentlichen Schlüssel der Distribution sind kritisch. Debian-Installer bringen die offiziellen Schlüssel mit. Updates der Schlüssel erfolgen über signierte Pakete - ein bootstrap-Problem, gelöst durch initiale Vertrauensstellung beim ersten Boot.
Drittanbieter-Repositories benötigen eigene Schlüssel. Ein PPA (Personal Package Archive) unter Ubuntu oder ein externes Repository bei Debian erfordert Import des Repository-Schlüssels. Ohne diesen Schlüssel verweigert die Paketverwaltung Installation - “Signatur kann nicht verifiziert werden”.
Metadaten-Format und Paket-Indizes
Metadaten beschreiben Pakete strukturiert. Ein Debian-Paket hat Felder wie Package:, Version:, Architecture:, Depends:, Description:. Diese Informationen liegen in Textdateien - die Paketverwaltung parst sie bei apt update.
Package: nginx
Version: 1.24.0-1
Architecture: amd64
Depends: libc6 (>= 2.34), libpcre2-8-0 (>= 10.32), libssl3 (>= 3.0.0)
Description: small, powerful, scalable web/proxy server
Nginx ("engine X") is a high-performance web and reverse proxy server
Die Metadaten-Dateien sind komprimiert (gzip, xz) und können Megabytes groß sein. Ein vollständiger Debian-Repository-Index hat über 100 MB - zehntausende Pakete mit Beschreibungen. Die Paketverwaltung cached diese Indizes lokal, Update lädt nur Änderungen.
Abhängigkeiten sind versioniert: libc6 (>= 2.34) bedeutet “libc6 Version 2.34 oder neuer”. Konflikte werden explizit deklariert: Conflicts: apache2 verhindert gleichzeitige Installation von nginx und apache2. Diese Metadaten ermöglichen automatische Abhängigkeitsauflösung.
Offizielle vs. Drittanbieter-Repositories
Offizielle Repositories sind distributions-gepflegt. Debian-Maintainer bauen und testen Pakete, signieren mit offiziellen Schlüsseln. Qualitätskontrolle ist hoch, Updates folgen Sicherheits-Policies. Pakete sind stabil, aber oft nicht die neuesten Versionen.
Drittanbieter-Repositories bieten neuere Software oder spezielle Pakete. Ein Postgres-Repository liefert die neueste PostgreSQL-Version, lange bevor Debian sie in stable übernimmt. Grafiktreiber-Repositories haben optimierte Builds für Gaming oder CUDA.
Das Risiko: Drittanbieter-Pakete können das System destabilisieren. Ein experimenteller Kernel aus einem PPA bringt neue Features - und potenzielle Bugs. Inkompatible Bibliotheks-Versionen aus Drittanbieter-Repos können offizielle Pakete brechen.
Manche Distributionen warnen vor Drittanbieter-Repos. Arch Wiki empfiehlt Vorsicht beim AUR - Pakete sind community-gepflegt, nicht offiziell geprüft. Debian-Nutzer werden gewarnt, wenn Pakete aus non-free oder externen Quellen stammen. OpenBSD bietet keine Drittanbieter-Mechanismen - nur offizielle Packages.
Repository-Prioritäten und Pinning
Mehrere Repositories können identische Pakete anbieten. nginx existiert in Debian stable, testing und möglicherweise einem Drittanbieter-Repo. Welche Version wird installiert? Repository-Prioritäten entscheiden.
Paketverwaltungen haben Standard-Prioritäten: Offizielle Repos haben Vorrang vor Drittanbieter-Repos, stable vor testing. Nutzer können Prioritäten überschreiben - APT Pinning auf Debian, Package Priorities auf anderen Systemen.
Ein Pinning-Beispiel: Debian stable nutzen, aber PostgreSQL aus testing installieren. Pinning bevorzugt PostgreSQL-Pakete aus testing, alle anderen aus stable. Diese Granularität verhindert vollständige System-Upgrades auf testing - nur ausgewählte Pakete werden aktualisiert.
Falsche Prioritäten verursachen Probleme. Ein Drittanbieter-Repo mit höherer Priorität als offizielle Repos kann bei Updates unerwartete Versionen installieren. Systeme werden instabil, Abhängigkeiten brechen. Vorsichtiges Pinning ist mächtig, unbedachtes Pinning gefährlich.
Repository-Updates und Verfügbarkeit
Repositories ändern sich. Neue Software-Versionen erscheinen, Sicherheitsupdates werden publiziert, alte Pakete werden entfernt. Die Paketverwaltung synchronisiert ihre lokale Paketliste regelmäßig - apt update, pacman -Sy, pkg_add -u laden die neuesten Metadaten.
Debian stable ändert sich minimal - nur Sicherheitsupdates. Debian testing und unstable ändern sich täglich. Arch Rolling Release aktualisiert kontinuierlich, OpenBSD current folgt der Entwicklung zwischen Releases.
Alte Pakete verschwinden aus Repositories. Ein Upgrade von Debian 11 auf Debian 12 macht alte Pakete unverfügbar - das Repository für Debian 11 wird irgendwann archiviert. Downgrade wird schwierig, alte Versionen müssen aus Archiv-Repos geladen werden.
Repository-Verfügbarkeit ist geschäftskritisch. Ein ausgefallenes Debian-Repository blockiert Updates und Neuinstallationen. Mirrors kompensieren, aber Archive-Server für alte Debian-Versionen laufen teils mit reduzierter Bandbreite. Produktions-Systeme sollten lokale Repository-Mirrors betreiben.
Bandbreite und Download-Optimierung
Paket-Downloads konsumieren Bandbreite. Ein Desktop-System mit täglichen Updates lädt 50-200 MB. Server mit vielen Paketen erreichen Gigabyte-Größen bei Major-Upgrades. Mirrors reduzieren die Last, aber Downloads bleiben relevant.
Delta-Updates übertragen nur Änderungen. Statt ein komplettes 50-MB-Paket neu zu laden, wird ein 5-MB-Delta auf das alte Paket angewendet. Arch unterstützt Delta-Pakete über zusätzliche Tools, Debian experimentiert damit, OpenBSD nutzt es nicht standardmäßig.
Lokale Caches sparen Bandbreite in Netzwerken. Ein Proxy-Server cached Pakete - zehn Rechner laden identische Updates nur einmal vom Internet, dann vom lokalen Cache. Tools wie apt-cacher-ng oder squid dienen als Paket-Caches in Firmen-Netzwerken.
Parallel-Downloads beschleunigen Updates. Die Paketverwaltung lädt von mehreren Mirrors gleichzeitig, nutzt volle Bandbreite. Alte Systeme luden seriell, moderne Versionen parallelisieren standardmäßig.
Repository-Sicherheit und Angriffsszenarien
Repositories sind Angriffsziele. Ein kompromittiertes Repository verteilt Malware an alle Nutzer. GPG-Signaturen schützen - ohne gültigen Signatur-Schlüssel kann ein Angreifer keine Pakete unterschieben. Der Schlüssel selbst ist kritisch geschützt.
Man-in-the-Middle-Angriffe versuchen, Downloads umzuleiten. HTTPS-Repositories verschlüsseln Verbindungen, verhindert Traffic-Manipulation. HTTP-Repositories sind anfälliger - GPG-Signaturen bleiben einzige Sicherheit. Moderne Distributionen bevorzugen HTTPS.
DNS-Spoofing kann Nutzer auf falsche Mirror-Server lenken. DNSSEC schützt, ist aber nicht universal. Die Kombination aus HTTPS und GPG-Verifikation macht Angriffe praktisch unmöglich - Angreifer müssten den privaten Signatur-Schlüssel der Distribution stehlen.
Repository-Kompromittierung passiert selten, hat aber massive Auswirkungen. Der Debian-Security-Vorfall 2003 führte zu verschärften Zugriffskontrollen. Distributionen trennen Signatur-Schlüssel physisch, erfordern Mehrfach-Authentifizierung, loggen alle Zugriffe. Sicherheit der Repositories ist existenziell für Distribution-Vertrauen.
Zusammenfassung
Repository-Systeme zentralisieren Software-Verteilung. Zentrale Server, geografisch gespiegelt, bieten tausende geprüfte Pakete. GPG-Signaturen sichern Authentizität, Metadaten beschreiben Pakete strukturiert. Offizielle Repositories garantieren Stabilität, Drittanbieter-Repos bieten Flexibilität mit Risiken.
Die Konzepte gelten distributionsübergreifend - APT auf Debian, pacman auf Arch, pkg_add auf OpenBSD nutzen Repository-Systeme mit Mirrors, Signaturen, Metadaten. Die Werkzeuge unterscheiden sich, die Architektur bleibt identisch.
Der nächste Artikel behandelt binäre vs. Quellcode-Pakete - vorkompilierte Software gegen selbst gebaute Programme.
Verwendete Software und Versionen
Diese Betrachtung bezieht sich auf:
- Repository-Konzepte: Universal für alle Unix-Systeme
- Beispiele: Debian, Arch Linux, OpenBSD
- Kontext: Distributionsübergreifende Grundlagen
- Stand: Oktober 2025
Weiterführende Schritte:
