Debian erhält sein eigenes AUR

Verfasst von

Was bei Arch Linux das AUR (Arch User Repository), ist bei Debian künftig das DUR (Debian User Repository). Dabei geht es in beiden Fällen um Pakete, die in den offiziellen Repositories der jeweiligen Distribution nicht oder nicht in aktueller Version vorliegen und deshalb von Usern für User in Form von PKGBUILD-Rezepten bereitgestellt werden.

Der Entwickler Hunter Wittenborn hat das Projekt erst vor wenigen Tagen vorgestellt. Er pendelte immer zwischen Arch Linux und Ubuntu hin und her, fand aber dessen PPAs inakzeptabel, was ihn zu DUR inspirierte. Es handelt sich dabei um kein offizielles Debian-Projekt, auch wenn die Aufmachung der Webseite dies vermuten lassen könnte.

Das Prinzip von DUR ist das gleiche wie beim AUR von Arch Linux. Die als PKGBUILD vorliegenden Anweisungen werden im Fall von DUR mit dem Tool makedeb zu einem installierbaren DEB-Paket geschnürt. Dabei nimmt Wittenborn das von Arch Linux verwendete makepkg als Grundlage. Noch in der Entwicklung steckt der Paketmanager mpm, der die Installation und Aktualisierung der resultierenden DEBs erleichtern soll. Zudem soll es zum Klonen von Paketen aus dem AUR und den Arch-Linux-Repositorien auf Debian und Debian-basierten Linux-Distributionen dienen. Das dritte Tool heißt makedeb-db und soll die Umsetzung der Abhängigkeiten von Arch-Paketen zu den Debian-Pendants übernehmen.

Das klingt für Debian Stable und Ubuntu wie eine segensreiche Ergänzung, jedoch gelten hier die gleichen Bedenken, die auch für das AUR gelten. Man kann den dort angebotenen Paketen nicht per se vertrauen. Da ist es hilfreich, wenn man die PKGBUILDs lesen und verstehen und somit die Sicherheit eines Pakets einschätzen kann. Weniger versierte Anwender müssen auf die Votes vertrauen, die ein Paket erhält.

Derzeit stehen erst 17 Pakete in der Liste, bleibt abzuwarten, ob das Projekt abhebt. Wer sich näher für DUR interessiert, sollte sich die Dokumentation ansehen. Einen Support-Kanal gibt es auf Matrix.

Debian GNU/Linux

Kommentare

27 Antworten zu „Debian erhält sein eigenes AUR“

2021-06-29

BuffaloBill

Witzig – Ich bin wegen AUR wieder weg von arch.

Das Problem ist nicht nur die Sicherheit, sondern auch die Kompatibilität. Das Problem hat Debian vielleicht etwas weniger, aber wenn man sich ein Rolling Release System hat (also ARCH) dann müssen diese Packagebuilds ordentlich gepflegt werden – und das ist längst nicht immer der Fall.

Essential wichtige Software Pakete? ja schau mal bei AUR! Äh der package Build ist zwei Jahre alt und lässt sich nicht mehr installieren? So what! Pech halt.

Bei Debian fehlt ja eigentlich fas nichts. Bisher habe ich alles, was man so braucht als Debian paket gefunden….

Antworten
1. 2021-06-29
  
  Martin Rüttler
  
  Nutze Manjaro und jedes Zweite Package lässt sich nicht installieren. Weiß nicht wieso, dazu untersuch ich nicgt die Fehlermeldungen.
  
  Gibt zwar fast alles wonach man sucht, aber beim Installieren rechne ich meist damit das was nicht installiert. Bin daher immer froh, wenn es das Programm auch in die offizielles Repos gibt.
  
  Antworten
2. 2021-06-29
  
  Tux
  
  Das ist einer der Gründe, die gegen Arch sprechen. Mangel an Paketen. Das AUR mag zwar viele davon beinhalten, ist aber inoffiziell, ungeprüft und somit ein Sicherheitsrisiko. In der Vergangenheit wurde bereits Malware gefunden:
  https://www.pro-linux.de/news/1/26074/malware-im-arch-user-repositorium-aur-gefunden.html
  
  Debian hingegen hat sehr viele Pakete für viele Architekturen. Lediglich Ungoogled Chromium fehlt, aber OBS schafft da Abhilfe.
  
  Antworten
  1. 2021-06-29
    
    kamome
    
    Danke für den Link, hatte ich nicht mehr auf dem Schirm.
    Ja, ohne PKGBUILD-Lesen (und Verstehen) wird es gefährlich.
    
    Antworten
3. 2021-06-29
  
  tuxnix
  
  Bei einem User-Repositorium wäre das eine Sache, bei der man sich als User auch mal einbringen kann. Für mich war das damals umgekehrt. Kubuntu hatte da nichts, nicht ein mal ein PPA und bei Arch konnte ich mit einem PKGBUILD aus den AUR sofort loslegen.
  
  Antworten
2021-06-29

wrohr

hatte nicht bisher auch für Debian der opensuse build service diese rolle übernommen ?

Antworten
2021-06-29

Charon

Sehr coole Idee, würde mir auch hier ähnlich wie im AUR sämtliche wifi Treiber und Firmware wünschen! Das erleichtert die Suche für Laptop Besitzer zum Bleistift.

Antworten
1. 2021-06-29
  
  Keine Sicherheit
  
  Wifi Treiber und Firmware gibt es im non-free repository, du musst es nur einbinden.
  
  Und wenn ein neues Erhaltungs-Release (Point Release) kommt, sind auch meist wieder neue Treiber dabei.
  Und Backports gibt es auch noch. Da kriegst du auch einen neuen Kernel.
  
  Antworten
  1. 2021-06-29
    
    Charon
    
    Danke für die Rückmeldung!!!
    
    Antworten
2021-06-29

Keine Sicherheit

Das untergräbt möglicherweise die Debian Backports, da nun Leute auf die Idee kommen könnten, ihr eigenes PPA (DUR) zu machen, ohne den Prozess die für Backports notwendig sind, durchlaufen zu müssen.

Da ist es hilfreich, wenn man die PKGBUILDs lesen und verstehen und somit die Sicherheit eines Pakets einschätzen kann. Weniger versierte Anwender müssen auf die Votes vertrauen, die ein Paket erhält.

Die Sicherheit eines Binärpakets kann man leider überhaupt nicht einschätzen, wenn man es nicht aus sicherem Quellcode selber baut und vergleicht, wofür wieder reproducible builds notwendig sind.

Und die Votes sind für die Sicherheit auch nicht aussagekräftig, da jeder seine Stimme dazu abgeben kann, unabhängig davon, ob er das Paket geprüft hat oder nicht und die meisten werden es nicht prüfen.
Die werden höchsten schauen ob es sauber funktioniert und regelmäßig updates bekommt und wenn es das tut, kriegt es gute Wertungen. Aber ob da eine Backdoor eingebaut ist, das prüft fast keiner nach.

Ich halte von dem ganzen Projekt daher nicht viel.
Wenn, dann müssen die Debian Backports mit mehr Manpower gestärkt werden, denn das ist der richtige Ort für neue Pakete, die in stable verfügbar sein sollen, aber nicht in den offiziellen main usw. repositories kein können.

Wenn man schon solche 3rd Party PPAs erlauben will, dann müsste man die Infrastruktur schon so machen, dass die in ihrer eigenen Sandbox laufen und auch nur eingeschränkten Zugriff zum Homeverzeichnis haben.
Das bieten zur Zeit die flatpaks. Wer also zwingend neue Software braucht, die sich nicht in den backports befinden ist sicherheitstechnisch mit den flatpaks besser bedient, eben weil die wenigstens in einer Sandbox kaufen.

Antworten
2021-06-29

wunderbar

Ok da würd mich jetzt doch interessieren, was an PPAs inakzeptabel ist?!

Hab Manjaro und irgend ne andere Arch basierte Distro mehrmals probiert, bin aber meist an nem durch AUR zerschossenen System gescheitert und hatte dann die Schnauze voll. Außerdem hänge ich wie die Pest an Synaptic, es gibt einfach keinen besseren grafischen Paketmanager da draußen…
Und wenn ich jedes 2. Paket kompilieren muss, kann ich auch gleich gentoo nutzen.

Mal eben nen PPA mit nem aktuellen Mesa oder Mesa-git „einhängen“oder raus schmeißen geht so leicht von der Hand, das will ich nicht missen.
Und ansonsten, wenn das Projekt größer ist, im Sinne von da steckt ne Firma mit drin, wird oft nen richtiges Repo angeboten.

Ok, ich muss mir alle PPAs selber raussuchen und hinzufügen, bevor ich was machen kann, aber damit kann ich leben. Dann pflegt man eben ne kleine Liste odr nen Script, dass bei ner Neuinstallation alle wieder hinzufügt…

Auf von Hinz und Kunz erstellte Blaupausen verzichte ich lieber und ergeben mir keinen höheren Sicherheitsaspekt als Pakete aus nem PPA, sollte das nen Grund sein…

Antworten
1. 2021-06-29
  
  kamome
  
  Ein wichtiger Unterschied ist, dass die PKGBUILD-Dateien ziemlich gut sichtbar sind, oder? Ich bevorzuge ja Debian – ohne PPAs 😉
  
  Antworten
2021-06-29

Zeitgeist

Eine weitere Distribution ist in der Gegenwart angekommen. Na wenn das kein Grund ist, die Korken knallen zu lassen.

Antworten
2021-06-29

tuxnix

Pakete selbst kompilieren mit einem PKGBUILD, dass man prüfen kann, ist sehr viel besser als PPAs aus zweifelhafter Quelle zu nutzen.
DUR ist keine schlechte Idee, zumal man sich wohl bald aus dem gesamten AUR-Pool bedienen kann. Maintainer wachen ja auch nicht auf Bäumen und da ist ein PKGBUILD schon eine gute Möglichkeit der Ergänzung.

Antworten
2021-06-30

Cinux

Also PPA ist gut DUR ist schlecht weil man dadurch die Sicherheit des Systems gefährdet. Aber mit Windows wiederum irgendwelche .exe oder .msi Dateien ausführen ist ok (Wahrscheinlich weil Industriestandard).

Also ich finde die Entwicklung erst einmal nicht schlecht.
Was daraus wird, wird sich zeigen.

Aber am ende steht und fällt jede Sicherheit durch den Anwender und nicht durch irgendwelche AUR/DUR/PPA/EXE/MSI Dinge. Zumal AUR und DUR von der community gepflegt wird und alle Welt erwartet das so etwas fehlerfrei und mit allem und jeden Kompatibel ist. (Wahrscheinlich ähnlich dem Klamotten Kauf. Eine L ist auch immer und überall eine L 😉 …. nicht )

Antworten
1. 2021-06-30
  
  tuxnix
  
  Ja, beim AUR muss der Anwender das PKGBUILD selbst kontrollieren.
  https://wiki.archlinux.de/title/AUR_Sicherheitshinweise
  Das ist ein fester Bestandteil dieses Konzepts.
  
  Antworten
2021-06-30

viebrix

Ich lese immer wieder man soll nicht aus anderen Quellen installieren weil das wäre ungeprüft. Verstehe ich im Prinzip und finde es super, dass es von den Distributionen Repositories gibt, welche zur Verfügung gestellt werden und geprüft sind. Aber wie gut sind diese wirklich geprüft? Kann man sich da dann wirklich verlassen. Wird hier wirklich geprüft ob da nicht ein Backdoor, oder Schadsoftware drinnen ist? Nach dem ich ja aus der Windows Welt erst in die Linuxwelt eintauche – kommt mir das ein bisschen wie ein Traum vor, aber das würde doch enorm viele Resourcen binden….

Antworten
1. 2021-06-30
  
  Ferdinand
  
  Prinzipiell ist das richtig. dass man möglichst bei den Repositories der Distribution bleiben sollte, was bei Debian auch nicht schwer ist bei der enormen Anzahl an Paketen. Je mehr Du Dich in die freie Wildbahn begibst, desto mehr Ahnung solltest Du haben, was Du da tust. Die Repositories sind grundsätzlich sehr sicher, da jeder Maintainer die Pakete mit seinem persönlichen Schlüssel signiert. Mir ist nur ein Fall erinnerlich, bei dem Mint-Downloads Schadsoftware enthielten. Aber Mint hat generell nicht den besten Ruf, wenn es um Sicherheit geht,
  
  Antworten
  1. 2021-06-30
    
    Charon
    
    Dürfte ich fragen wieso, Linux Mint was Sicherheit betrifft einen schlechten Ruf hat?
    
    Antworten
    1. 2021-06-30
      
      Ferdinand
      
      Wenn eine Distribution Schadsoftware in ihren Abbildern ausliefert, dann ist der gute Ruf halt dahin. Zudem war das nicht der einzige Vorfall.
      
      Antworten
      1. 2021-06-30
        
        Charon
        
        Vielen Dank für die schnelle Antwort.
2. 2021-06-30
  
  Keine Sicherheit
  
  Bei Debian sid stammt der Code direkt von upstream, also den Hauptentwicklern von deren Projektwebseite und wird auch nur als Diff eingebaut, nicht als kompletter Tarball. So bleiben die Änderungen von Version zu Version zumindest bei kleinen Projekten überschaubar.
  
  Und wenn Patches in die testing und stable Pakete einfließen, dann gibt’s dazu nen diff, über den der Maintainer zumindest drüberguckt, denn am Ende signiert er das mit seiner digitalen Unterschrift.
  
  Da müsste die Backdoor also schon direkt bei den Hauptentwicklern, also vor Debian, eingebaut werden, aber die werden wohl ihr Kind nicht kaputt machen lassen wollen, zumal sie mit Namen etwas zu verlieren haben. Also gucken auch die danach, dass niemand am Code rumpfuscht.
  
  Dennoch ist es natürlich möglich, dass sich ein Entwickler Vertrauen erschleicht, ne ganze Weile gute Arbeit leistet und dann irgendwann ein paar komplizierte Änderungen einbaut, die auf den ersten Blick nicht mal als Sicherheitslücke erkennbar sind, aber unter bestimmten Konstellationen eine sind.
  Das wird er dann aber so machen, dass es mehr wie ein Bug aussieht, der sich exploiten lässt, als eine umfangreich programmierte Backdoor.
  Die umfangreichen Backdoorfunktionen werden dann eher als Exploit nachgeschoben, wenn die Software dann installiert ist und man diese Sicherheitslücke dann ausnutzen kann.
  Das könnte bspw. bei Heartbleed der Fall gewesen sein.
  
  Bei solchen PPAs aber, wo binaries verteilt werden. Wäre es gut möglich, dass man eine voll funktionstüchtige und auch getestete Backdoor mit umfangreichen Funktionen gleich ins Binary einbaut. Wenn der PPA Ersteller schlau ist, dann verbindet sich die Backdoorfunktion nur zu gewissen Zeiten mit dem Kontrollserver. Dann fällt das auch nicht auf den ersten Blick auf, wenn jemand die über PPA geholte Software sich mal kurz ansieht und guckt, ob die nach draußen „funkt“.
  Als Nutzer kann man das Binarie nicht überprüfen. Selbst wenn man, wie oben schon erwähnt, so einen reproducible build Test durchführt, also das PPA Zeug nochmal aus dem Quellcode baut, muss das nichts bedeuten, denn es kann auch sein, dass sich das Paket nicht als reproducible build bauen lässt. Weil bspw. andere Variblenwerte usw. verwendet wurde.
  Dann weiß man nur, dass ich das eigene binary vom binary des PPA Erstellers unterscheidet, das könnte aber auch ein false positive sein.
  Und wenn man sich schon das antut, dann bruacht man das PPA Zeug ohnehin nicht, denn dann kann man auch gleich direkt selber sein Paket erstellen und aus dem vanilla Quellcode erzeugen.
  
  Letzten Endes gibt es eine absolute Sicherheit nur mit einem Code Audit, aber das ist bei > 60000 Paketen ohnehin nicht machbar.
  Also läuft es auf Vertrauen hinaus. Dieses ist bei Hauptentwicklern und einer Distribution wie Debian, die beide etwas zu verlieren haben und sich auch darum kümmern, dass Änderungen Schritt für Schritt nachvollziehabr sind (kleine Diffs) aber weitaus eher drin, als bei irgendeinem dahergelaufenen Wald und Wiesen PPA Ersteller, den kein Mensch kennt und der auch noch gleich Binaries liefert.
  
  Oder anders gesagt, wenn du einem PPA Ersteller vertraust, dann kannst du auch bspw. meinem Programm vertrauen, wenn ich dir so eines in einer tar.gz Datei als E-Mail verschicke.
  
  Antworten
  1. 2021-06-30
    
    tuxnix
    
    Du hast das sehr toll beschrieben. Im Wesentlichen beruht die Sicherheit von Software auf der Nachvollziehbarkeit. Die ist bei PPAs eben nicht gegeben.
    Ebenso ist dies bei snaps und flatpaks, die man nur aus der Quelle seines Vertrauens installieren sollte.
    
    Antworten
3. 2021-07-01
  
  viebrix
  
  Danke für die detailreichen Antworten!
  
  Antworten
2021-07-03

detlef-s

Debian und AUR? klingt erst mal interessant, aber macht das bei Debian wirklich Sinn? Hatte bisher keine Probleme, bei Debian, oder Debian-basierten Systemen etwas passendes zu kriegen. Aber solange die nicht mit Flatpack oder Snap anfangen, ich bevorzuge eh deb-Pakete.

Antworten
1. 2021-07-03
  
  Ferdinand
  
  Jede Jeck is anders, wie man in Köln sagt. Und so finden sich bestimmt auch Debian-Anwender, die Bedarf an DUR haben. Debian Sid ist zwar wesentlich näher am Geschehen als die Stable-Ausgabe, allerdings ist auch nicht immer »bleeding edge«. Aber um benutzbar zu sein, muss sich DUR erstmal durchsetzen. Und da habe ich so meine Zweifel.
  
  Antworten
2021-08-29

Matthias

Und schon wieder eingestampft so wie aussieht. Weil kein Bock. Auf jedenfall ist das github Repisitory archiviert.

„DEPRECATION NOTICE

mpm is no longer supported due to a change of direction in my development.

Users wishing to continue receiving support should consider moving over to tap or any other MPR helper.“

Antworten