Eine Paket-Quelle ist der Server, von dem dein System Software bezieht. Jede Distribution liefert eine sorgfältig kuratierte Default-Liste mit, doch sobald du Software von Drittanbietern installieren willst — sei es ein Docker-Repo, ein PPA für eine neuere Version oder ein RPM-Repo eines Herstellers — kommst du an den eigentlichen Mechanismen nicht vorbei. Dieser Artikel zeigt, wie Repos, Mirrors, PPAs und GPG-Signaturen zusammenspielen und wie das Vertrauensmodell aufgebaut ist.

01 · Abschnitt

Was eine Paket-Quelle ist

Eine Paket-Quelle (Repository) ist im Kern ein Webserver, der zwei Dinge bereitstellt: eine Paket-Liste (Index aller verfügbaren Pakete mit Metadaten und Hashes) und die Pakete selbst als .deb-, .rpm- oder .pkg.tar.zst-Archive. Beides ist mit einem GPG-Schluessel des Repository-Betreibers signiert.

Wenn du ein Paket installierst, läuft im Hintergrund immer derselbe Ablauf:

  1. Der Paketmanager liest die konfigurierten Quellen.
  2. Er laedt die signierte Paket-Liste herunter und prüft die Signatur gegen die lokal installierten öffentlichen Schluessel.
  3. Findet sich das gewünschte Paket, wird es heruntergeladen und sein Hash gegen den Eintrag in der Liste geprüft.
  4. Erst danach wird das Paket entpackt und installiert.

Das Vertrauensmodell ist also zweistufig: Die Liste bestätigt, welche Hashes erwartet werden — die Signatur bestätigt, dass die Liste vom legitimen Betreiber stammt. Wer einem Repository vertraut, vertraut seinem GPG-Schluessel und damit allem, was darüber installiert wird.

02 · Abschnitt

Wo Quellen konfiguriert sind

Jede Distribution legt ihre Quellen-Konfiguration an einem eigenen Ort ab. Das Format unterscheidet sich, das Prinzip nicht.

DistributionHauptdateiDrop-in-VerzeichnisFormat
Debian / Ubuntu/etc/apt/sources.list/etc/apt/sources.list.d/*.list (klassisch) oder *.sources (Deb822, modern)
Fedora / RHEL / Rocky—/etc/yum.repos.d/*.repo (INI-ähnlich)
Arch Linux/etc/pacman.conf/etc/pacman.d/mirrorlistINI mit Server-Einträgen
openSUSE—/etc/zypp/repos.d/*.repo
Alpine/etc/apk/repositories—Eine URL pro Zeile

Die wichtigste Konvention quer über alle Distributionen: eine Datei pro Drittanbieter-Repository. Das macht es trivial, ein Repo wieder zu deaktivieren — du löschst oder benennst die Datei um, und der Eintrag verschwindet aus dem System.

03 · Abschnitt

Aufbau einer Debian-Source-Zeile

Die klassische *.list-Syntax für Debian und Ubuntu ist eine Zeile pro Repository. Jeder Teil hat eine konkrete Bedeutung.

Bash /etc/apt/sources.list.d/example.list 
deb [signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable

Die Felder im Detail:

FeldWert im BeispielBedeutung
Typdebdeb für Binärpakete, deb-src für Quellpakete
Optionen[signed-by=...]In eckigen Klammern: hier die Bindung an einen bestimmten GPG-Schluessel
URLhttps://download.docker.com/linux/ubuntuBasis-URL des Repository-Servers
DistributionjammyCodename der Distro-Version (Ubuntu 22.04 = jammy)
KomponentenstableEin oder mehrere Bereiche des Repos, getrennt durch Leerzeichen

Das moderne Deb822-Format *.sources druckt dieselben Informationen lesbarer als Block aus.

Bash /etc/apt/sources.list.d/docker.sources 
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: jammy
Components: stable
Signed-By: /etc/apt/keyrings/docker.gpg

Beide Formate sind funktional aequivalent. Neue Setups sollten Deb822 nutzen — es ist mehrzeilig, kommentierbar und unterstuetzt Mehrfachwerte sauberer.

04 · Abschnitt

Mirrors

Ein Mirror ist eine geographisch verteilte Spiegelkopie des Original-Repositories. Anstatt dass alle Welt von einem zentralen Debian-Server in Europa lädt, gibt es Mirrors in jedem größeren Land — schneller für den Endnutzer und weniger Last für das Original.

Wie Mirrors konfiguriert werden, unterscheidet sich pro Distro:

DistributionMechanismusWerkzeug
DebianURL in sources.list zeigt direkt auf den Mirrormanuell oder netselect-apt
Ubuntu”Software & Updates”-GUI oder Eintrag in sources.listsoftware-properties-gtk
Arch LinuxListe in /etc/pacman.d/mirrorlist, oben steht der bevorzugtereflector zum Auto-Sortieren
FedoraEintrag metalink=...mirrors.fedoraproject.org/... wählt automatischDNF erledigt das selbst
openSUSEMirrorBrain-Service auf download.opensuse.orgAutomatisch

Für Arch Linux laesst sich der Mirrorlist mit reflector automatisch nach Geschwindigkeit und Aktualität sortieren.

Bash Arch-Mirrors nach Geschwindigkeit sortieren 
sudo reflector --country DE --age 6 --sort rate --save /etc/pacman.d/mirrorlist

Der Befehl wählt deutsche Mirrors aus, die in den letzten 6 Stunden synchronisiert wurden, und sortiert sie nach gemessener Download-Rate. Das Ergebnis überschreibt die bestehende mirrorlist.

Bei Fedora ist das Mirror-Routing in den Default-Repos bereits aktiv: Das Feld metalink zeigt auf einen zentralen Service, der pro Anfrage die schnellsten Mirrors zurückgibt. Du musst also nichts tun.

05 · Abschnitt

PPAs — Personal Package Archives

PPAs sind eine Ubuntu-Spezialität. Sie werden vom Launchpad-Service (von Canonical betrieben) gehostet und ermöglichen es einzelnen Entwicklern oder Teams, eigene .deb-Pakete zu verteilen, ohne einen Mirror oder eigenen Server betreiben zu müssen.

Hinzufügen ist ein Einzeiler:

Bash PPA für den Mozilla-Team-Build 
sudo add-apt-repository ppa:mozillateam/ppa
sudo apt update

Hinter den Kulissen passiert dabei genau das, was du auch manuell machen könntest: Eine .list-Datei wird in /etc/apt/sources.list.d/ angelegt, und der zugehörige GPG-Schluessel wird vom Launchpad-Keyserver importiert.

PPAs sind bequem, aber kein offizieller Audit-Prozess liegt dahinter. Wer ein PPA hinzufügt, vertraut dem PPA-Eigentuemer komplett — der Eigentuemer kann jederzeit beliebige Pakete pushen, die mit Root-Rechten installiert werden. Nutze nur PPAs von bekannten Maintainern, Projekten oder Firmen.

06 · Abschnitt

GPG-Keys und Signaturen

Jedes Repository signiert seine Paket-Liste mit einem GPG-Schluessel. Damit dein System diese Signatur prüfen kann, muss der öffentliche Schluessel des Repository-Betreibers lokal vorliegen.

Für die Default-Repos der Distribution sind diese Schluessel bereits beim Setup installiert (zum Beispiel in den Paketen debian-archive-keyring, ubuntu-keyring oder fedora-gpg-keys). Bei Drittanbieter-Repos musst du den Schluessel selbst importieren.

Der moderne Weg unter Debian und Ubuntu speichert den Schluessel in /etc/apt/keyrings/ und bindet ihn über die signed-by-Option an genau das Repository. Damit hat ein Drittanbieter-Schluessel nur Vertrauen für sein eigenes Repo — nicht für das gesamte System.

Bash GPG-Key für ein Drittanbieter-Repo importieren 
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Die Schritte im Einzelnen:

  • install -m 0755 -d legt das Verzeichnis mit korrekten Rechten an, falls es noch fehlt.
  • curl -fsSL laedt den ASCII-armored Schluessel.
  • gpg --dearmor wandelt das ASCII-Format in das von APT erwartete binäre Keyring-Format um.
  • chmod a+r macht die Datei für alle Nutzer lesbar — APT läuft beim update als _apt-User, nicht als Root.

Anschließend wird das Repository mit der signed-by-Option auf genau diesen Keyring eingetragen.

Bash Repository mit Bindung an den Keyring eintragen 
echo "deb [signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
07 · Abschnitt

Repository-Stages und -Komponenten

Jede Distribution unterteilt ihren Software-Bestand in Stages (Stabilitätsgrade) und Komponenten (Lizenz- und Support-Kategorien). Wer ein Repository hinzufügt, sollte wissen, in welchen Bereich er sich begibt.

DistributionStages / KomponentenVertrauen / Stabilität
DebianstableProduktionsreif, getestet, ca. 2-Jahres-Zyklus
DebiantestingNächste Stable, in Vorbereitung — meist brauchbar
Debianunstable (sid)Aktuelle Pakete, gelegentlich kaputt
DebianexperimentalHöchst riskant, nur für Tests
Debianmain / contrib / non-free / non-free-firmwareKomponenten nach Lizenz
UbuntumainCanonical-Support, freie Software
UbunturestrictedProprietaere Treiber mit Canonical-Support
UbuntuuniverseCommunity-gepflegt, freie Software
UbuntumultiverseSoftware mit Lizenz-Einschränkungen
Ubuntu-security, -updates, -backportsSuites pro Komponente für Security- und Update-Streams
FedorafedoraStable Release
FedoraupdatesSicherheits- und Bugfix-Updates
FedorarawhideRolling Development-Stream
ArchcoreBasis-System, eng kuratiert
ArchextraOffiziell unterstuetzte Zusatzpakete
Archmultilib32-Bit-Bibliotheken auf 64-Bit-Systemen
ArchAURCommunity-Build-Skripte, kein offizielles Repo

Faustregel: Auf Produktivsystemen ausschließlich stable-Stages plus Security-/Updates-Streams. testing und unstable sind etwas für Entwicklungsmaschinen oder neugierige Nutzer.

08 · Abschnitt

Praxis-Patterns

Die folgenden Patterns decken die häufigsten Aufgaben rund um Paket-Quellen ab. Jeder Block beschreibt, was passiert und wann du ihn brauchst.

Drittanbieter-Repo unter Debian/Ubuntu hinzufügen (modern)

Der saubere Weg, ein neues Repository einzurichten: Schluessel in /etc/apt/keyrings/, Repository mit signed-by an genau diesen Schluessel binden.

Bash Repo mit Schluessel-Bindung einrichten 
# 1. Keyring-Verzeichnis sicherstellen
sudo install -m 0755 -d /etc/apt/keyrings

# 2. GPG-Schluessel importieren
curl -fsSL https://example.com/repo/key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

# 3. Repository mit Bindung an den Schluessel eintragen
echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/repo stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

# 4. Paket-Listen aktualisieren
sudo apt update

Schritt 4 ist Pflicht — ohne apt update kennt das System die neuen Pakete nicht.

PPA hinzufügen (Ubuntu)

Der bequemste Weg für Ubuntu-Nutzer. add-apt-repository legt automatisch eine .list-Datei und den passenden Keyring an.

Bash Mozilla-PPA hinzufügen 
sudo add-apt-repository ppa:mozillateam/ppa
sudo apt update

Mit sudo add-apt-repository --remove ppa:mozillateam/ppa laesst sich das PPA später wieder entfernen.

Repository unter Fedora/RHEL hinzufügen

Unter Fedora und seinen Derivaten ist dnf config-manager das Standardwerkzeug. Es laedt eine .repo-Datei und legt sie unter /etc/yum.repos.d/ ab.

Bash Docker-Repo unter Fedora 
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf makecache

dnf makecache aktualisiert die lokalen Metadaten — analog zu apt update.

Arch-Mirrors automatisch sortieren

reflector ruft die offizielle Mirror-Liste ab, filtert nach Land und Aktualität und sortiert nach gemessener Geschwindigkeit. Vor dem Schreiben empfiehlt sich ein Backup.

Bash Mirrors für DE optimieren 
sudo cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak
sudo reflector --country DE --age 6 --sort rate --save /etc/pacman.d/mirrorlist
sudo pacman -Syy

pacman -Syy erzwingt das Neuladen der Paket-Datenbanken aus den neuen Mirrors.

EPEL aktivieren (RHEL / Rocky / AlmaLinux)

EPEL (Extra Packages for Enterprise Linux) ist das Community-Repository, das Tausende Pakete liefert, die nicht Teil des Enterprise-Kerns sind. Auf RHEL-Derivaten wird es typischerweise zuerst aktiviert.

Bash EPEL einschalten 
sudo dnf install -y epel-release
sudo dnf makecache

Das Paket epel-release enthält sowohl die .repo-Datei als auch den GPG-Schluessel — du musst nichts manuell importieren.

09 · Abschnitt

Häufige Stolperfallen

apt-key add ist deprecated — nutze signed-by und keyrings.

Lange Zeit war apt-key add der Standardweg, GPG-Schluessel zu importieren. Die Schluessel landeten in einem globalen Keyring unter /etc/apt/trusted.gpg.d/ und galten damit für alle Repositories. Ein einziger kompromittierter Drittanbieter-Schluessel konnte so beliebige Pakete validieren — auch für das Haupt-Repository. Seit Debian 11 und Ubuntu 22.04 ist apt-key als deprecated markiert. Der moderne Weg legt den Schluessel in /etc/apt/keyrings/ ab und bindet ihn per signed-by-Option ausschließlich an das jeweilige Repository. Damit ist das Vertrauen scoped, und jedes Repo trifft nur seine eigene Tasche.

PPAs sind nicht auditiert — der Eigentuemer kann alles pushen.

Ein PPA ist im Endeffekt ein freier Upload-Slot bei Launchpad. Es gibt keinen Code-Review, keinen Sicherheits-Audit, keine Prüfung der enthaltenen Binaries. Wer ein PPA hinzufügt, vertraut dem Eigentuemer vollständig — der kann jederzeit Pakete mit beliebigen Maintainer-Skripten pushen, die mit Root-Rechten ausgeführt werden. Das ist kein theoretisches Risiko: In der Vergangenheit wurden gekaperte PPAs als Vektor für Cryptominer und Backdoors genutzt. Beschränke dich auf PPAs von bekannten Projekten, Firmen oder Personen mit Reputation.

Mehrere Quellen mit identischem Paket führen zu Pinning-Konflikten.

Wenn zwei aktive Repositories dasselbe Paket in unterschiedlichen Versionen anbieten, muss APT entscheiden, welches gewinnt. Standardmäßig wählt es die höchste Version — aber das ist oft genau das, was du nicht willst, etwa wenn ein PPA versehentlich eine kritische System-Bibliothek überschreibt. Die Lösung heißt APT-Pinning in /etc/apt/preferences oder /etc/apt/preferences.d/: Du legst Prioritäten pro Quelle fest. Versaeumst du das, kann ein einzelnes neues Repo deine System-Pakete in eine Version zwingen, die mit deinem Distro-Unterbau nicht harmoniert.

Stable und Testing mischen bricht das System.

Es klingt verlockend, ein einzelnes Paket aus Debian Testing oder Unstable zu ziehen, weil dort eine neuere Version liegt. Das Problem: Pakete in Testing sind gegen die Bibliotheken aus Testing gebaut. Sobald du eines installierst, zieht es seine Abhängigkeiten nach — und die ziehen wieder ihre Abhängigkeiten — bis halbe Bibliotheksbestände überschrieben sind. Das Ergebnis ist häufig ein nicht mehr bootfähiges System. Wenn du wirklich mischen musst, nutze Pinning mit niedriger Priorität für Testing und installiere gezielt mit apt install -t testing paketname — und auch das nur mit Vorsicht.

GPG-Keys werden rotiert — alte Repos schlagen ploetzlich fehl.

Repository-Betreiber tauschen aus Sicherheitsgruenden gelegentlich ihre Signatur-Schluessel aus. Wenn das passiert und du den alten Key importiert hast, scheitert apt update mit einer Signatur-Fehlermeldung — typischerweise NO_PUBKEY oder EXPKEYSIG. Die Lösung ist, den neuen Schluessel zu importieren und den alten zu entfernen. Bei größeren Anbietern (Docker, Microsoft, Google) findest du die aktuellen Schluessel in deren Setup-Dokumentation. Auf langlebigen Servern, die nur selten gepflegt werden, ist das einer der häufigsten Stolpersteine.

Nach jedem Repo-Add ist apt update Pflicht.

Ein neu hinzugefügtes Repository ist erst dann nutzbar, wenn die Paket-Liste lokal vorliegt. Ohne sudo apt update sieht apt install die neuen Pakete nicht — und die Fehlermeldung “Unable to locate package” wirkt erstmal mysterioes. Gewoehne dir an, nach jedem Eintrag in sources.list.d/ sofort apt update auszuführen. Bei Fedora ist es dnf makecache, bei Arch pacman -Sy.

Format *.list ist deprecated, *.sources (Deb822) ist modern.

Die klassische Einzeiler-Syntax in .list-Dateien funktioniert nach wie vor, ist aber schwer lesbar und verleitet zu Fehlern — gerade die Optionen in eckigen Klammern werden gerne vergessen oder vertippt. Das Deb822-Format in .sources-Dateien schreibt jeden Eintrag als mehrzeiligen Block mit benannten Feldern. Das ist nicht nur lesbarer, es erlaubt auch Mehrfachwerte (mehrere URIs, mehrere Suites) und Kommentare innerhalb eines Eintrags. Neue Setups sollten .sources verwenden — Debian 12 und Ubuntu 24.04 nutzen das Format intern bereits standardmäßig.

10 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Pakete

Zur Übersicht