Ubuntu Snap Store enthielt Malware

[MSfree]

MSfree scheint absolute Forderungen von Wahrscheinlichkeiten nicht unterscheiden zu können.

Ich glaube, ich kann ganz gut mit Wahrscheinlichkeiten und Statistik umgehen

Die Tatsache, daß das Debianrepo besser kontrolliert und abgesichert ist, bedeutet nur eine geringere Wahrscheinlichkeit, daß es einen erwischt. Eine Wahrscheinlichkeit, die nicht Null ist, bedeutet nunmal, daß es auch Debian möglicherweise erwischen kann. Und wenn es Debian dann doch erwischt, nützt einem eine Wahrscheinlichkeit von eins zu 100 Millionen nichts, wenn die Schadsoftware auf dem eigenen Rechner hockt.

In diesem unwahrscheinlichen Fall werde ich mir dann im Ubuntuforum die Debianhäme mit einem Eimer Popcorn bewaffnet durchlesen.

[Nice]

@MSfree:

Ich glaube, ich kann ganz gut mit Wahrscheinlichkeiten und Statistik umgehen.

Nicht mit dem, was Du hier im Thread schreibst.

Beispiel:

Eine Wahrscheinlichkeit, die nicht Null ist

... gibt es fast nie.
Solch ein Ansinnen - ich wiederhole mich - nivelliert alle Versuche verantwortlichen Handelns.

P.S,:
Auch Sprüche wie "Popkorn", "AluHut" etc. sind in diesem Zusammenhang Tinnef.

[TomL]

Wer kennt heute noch CICS 3270-Terminals, TSO VTAM usw.

Ich...habe ich auch mit gearbeitet...lang ist's her....

Ich auch... Roscoe... *ööörks*... mannomann... sind wir schon alt... ... ...

[KP97]

CICS runterfahren...Band einhängen...Backup machen...
Wir sind alt...und OT...

[breakthewall]

... und wenn es jemand gelingt, in die Repositoryserver verseuchte Softwarepakete einzuschleusen, hat man dann auch ganz schnell und zuverlässig Malware auf seinem Rechner. Es ist zwar schon lange her, aber auch das Debianrepository war schonmal kompromitiert (2003).

Auch im Sourcecode des Linuxkernels wurde bereits Schadcode eingeschleust.

Sicherlich ist früher so einiges passiert, doch gerade unter Debian hat man seither sehr daraus gelernt. Das würde mich sehr wundern wenn das jemals wieder möglich sein sollte. Das hätte doch längst passieren müssen. Und dank starker Kryptographie und verteilten Git-Repositories, ist eine Manipulation am Linux-Kernel so ziemlich nutzlos. Das letzte Mal konnte das schnell und problemlos wiederhergestellt werden, und dann ging es auch schon zum Regelbetrieb über.

Man kann sich zwar hinstellen und hämisch grinsen, daß es Ubuntu erwischt hat, aber Schadcode in Snappacks oder Flatpacks lassen sich auch unter Debian nicht ausschließen. Man kann die angebotenen Softwarepakete nur ständig kontrollieren und auf Anzeichen von Schadcode kontrollieren, was dann der Katz- und Mausjagd mit einem Virenscanner unter Windows entspricht. Zu behaupten, das könne unter Debian nicht passieren, wäre aber sehr vermessen.

Nun ja es ist sehr auffällig wie oft sich Canonical in dieser Hinsicht präsentiert, wobei es nicht mal konkret um Ubuntu geht. Dennoch ein No-Go diese mangelnden Prüfungen im Snap-Store. Bei Flatpaks bzw. Flathub, stehen Upstream-Pakete im Vordergrund, und maßgeblich proprietäre Software aus bekannten Quellen. Da kann nicht einfach jeder ankommen und beliebige Flatpaks hochladen. Und davon abgesehen kann man Flatpaks auch direkt beziehen, wie man am Beispiel Gimp sieht.

Doch der Vergleich mit Windows hinkt dennoch stark, da hier weder zentrale Repositories existieren, noch einheitlich aktualisiert werden kann, noch auch nur irgendein Programm von Haus aus, stark mittels Sandboxing isoliert wird. Und läuft zudem noch Wayland im Hintergrund, dann können grafische Flatpaks noch besser isoliert werden, was es so unter Windows gar nicht gibt. Auch wenn man fairerweise sagen muss, dass die Situation unter Windows etwas besser ist, als unter einem X-Server unter GNU/Linux. Dennoch ist die Isolation grafischer Programme, unter allen Betriebssystemen gleichermaßen beschissen. Umso besser das sich das nun zum Teil verbessert.

Letztlich muss ich auch sagen, dass das Konzept der Snaps und Flatpaks an sich funktioniert, und auch schützt, doch Krypto-Miner sind wieder ein Fall für sich. Denn im eigentlichen Sinne ist das ja keine typische Schadsoftware, und greift ebenso intensiv auf Systemressourcen zu wie ein legitimes Programm. Die Frage ist wie man das vorab erkennt, und insbesondere ohne Quellcode je nachdem. Da muss auch der Nutzer mit arbeiten, indem nicht einfach Snaps/Flatpaks aus dubiosen Quellen, und von unbekannten Entwicklern bezogen werden. Andererseits muss man das alles auch nicht nutzen.

[breakthewall]

Die Tatsache, daß das Debianrepo besser kontrolliert und abgesichert ist, bedeutet nur eine geringere Wahrscheinlichkeit, daß es einen erwischt. Eine Wahrscheinlichkeit, die nicht Null ist, bedeutet nunmal, daß es auch Debian möglicherweise erwischen kann. Und wenn es Debian dann doch erwischt, nützt einem eine Wahrscheinlichkeit von eins zu 100 Millionen nichts, wenn die Schadsoftware auf dem eigenen Rechner hockt.

Richtig. Doch mindestens genauso wichtig sind erweiterte Sicherheitsmaßnahmen, anstatt sich nur darauf zu verlassen, dass seitens des Repository schon alles sauber ist. Nicht umsonst gibt es VMs, SELinux, AppArmor, Sandboxing in vielerlei Hinsicht, und Möglichkeiten auch Root einzuschränken. Hier und da kann es auch nicht schaden, eine Test-Installation zu haben, bevor man sich sein reales System mit Schadsoftware ruiniert. Anhand einer VM würde man schon sehen, wenn hier urplötzlich massiv Systemressourcen verbraucht werden. Und gegen Krypto-Miner im Browser, hilft ja bekanntlich NoScript und dergleichen.

[MSfree]

Doch der Vergleich mit Windows hinkt dennoch stark, da hier weder zentrale Repositories existieren, noch einheitlich aktualisiert werden kann, noch auch nur irgendein Programm von Haus aus, stark mittels Sandboxing isoliert wird.

Nunja, unter Windows hat es sich allgemein durchgesetzt, daß auf jedem Rechner ein "Wächter" (AKA Virenscanner) läuft, der aufpaßt, daß Schadsoftware sich gar nicht erst einnistet.

Wie sonst soll man denn Softwarepakete vor der Installation auf mögliche Schadsofteware untersuchen?

Die Debianantwort lautet halt: vertrau den Repositories und halte dich von Fremdsoftware fern.

Das erste Problem ist, daß man dabei den Debianrepositories vertrauen soll. Bisher ist wenig passiert und die Auswirkungen von kompromitierter Software waren gering. Aber auch der SSH-Fehler, der nur im Debianrepository aufgetreten ist (fehlende Entropie hatte die Zahl der generierbaren SSH-Schlüssel auf 65536 limitiert), war nicht ganz ohne, bis zur Entdeckung und Behebung ist damals gefährlich viel Zeit vergangen. Es kommt also nicht nur durch gezielte Angriffe zu Sicherheitslücken, auch Unfälle gibt es immer wieder, und dagegen helfen auch keine Virenwächter.

Das zweite Problem ist, daß man manchmal eben Software braucht, die nicht in den Repos ist. Natürlich sollte man jeder Software ein gesundes Maß an Mißtrauen entgegen bringen, und Software, die nur zur Unterhaltung dient, kann man in der Regel problemlos meiden. Wenn es aber um produktive Software geht, bleibt nur das Vertrauen, daß es schon gut gehen wird. Mit einem Virenscanner könnte man hier zumindest auf bekannte Schadsoftware testen, aber das ist eben ein Katz- und Mausspiel, das man letzten Endes nur verlieren kann.

Versteh mich nicht falsch, ich bin kein Befürworter von Virenscannern. Die Viren, die mich bisher unter Windows angreifen wollten, habe ich mit Brain 1.0 erkannt, wo der installierte Virenscanner noch tagelang ahnungslos war, bevor die Signaturupdates dann doch zu einer Erkennung geführt haben.

Und läuft zudem noch Wayland im Hintergrund, dann können grafische Flatpaks noch besser isoliert werden,

Isolation ist in diesem speziellen Fall eines Cryptominers aber ziemlich wirkungslos. Der Miner hat ja in der Regel gar nicht zum, Ziel, das System anzugreifen, der will "nur" Rechenkapazität stehlen und das klappt auch in der Isolation ganz gut. Hier hilft nur, daß Verhalten das System wirklich gut zu kennen und unerwartet hohe CPU/GPU-Last rechtzeitig zu erkennen und zu analysieren. Auf Servern, die auch ohne Schadsoftware am Lastlimit arbeiten, ist die zusätzlich Aktivität eine Miners aber nicht unbedingt einfach und schnell erkennbar, erstrecht, wenn der Miner sich geschickt tarnt.

Wie gesagt, mir gefällt die Häme nicht, die man Ubuntu gerade entgegen bringt. Wer im Glashaus sitzt, sollte im Dunkeln kacken.

[Nice]

@MSfree:

Wie gesagt, mir gefällt die Häme nicht, die man Ubuntu gerade entgegen bringt.

Kein Mensch hier im Thread hat irgendwie Häme gegenüber Ubuntu gezeigt...
Was schreibst Du nur für einen Unsinn.
Es ging um Snap und dessen schlechte Pflege/Qualitätssicherung.

[breakthewall]

Nunja, unter Windows hat es sich allgemein durchgesetzt, daß auf jedem Rechner ein "Wächter" (AKA Virenscanner) läuft, der aufpaßt, daß Schadsoftware sich gar nicht erst einnistet.

Das Antivirenprogramm das Windows mehrfach durch sehr ernste Sicherheitslücken in Bedrängnis brachte? Ich würde dem nicht vertrauen.

Wie sonst soll man denn Softwarepakete vor der Installation auf mögliche Schadsofteware untersuchen?

Die Debianantwort lautet halt: vertrau den Repositories und halte dich von Fremdsoftware fern.

Hier ist eben primär der Maintainer gefragt. Und unter Debian hätte man noch das Audit-Team, was insbesondere den Quellcode wichtiger und gefährdeter Pakete, mittels automatisierter Programme durchforstet. Ist zumindest ein Ansatz um Sicherheitslücken aufzudecken. Und was unliebsame Verhaltensweisen angeht, so ist der Zeitraum bis ein Paket das Stable-Repository erreicht ziemlich lange, womit vieles recht wahrscheinlich zuvor auffallen wird. Bislang scheint es zu funktionieren. Ansonsten kann der Nutzer selbst mit erweiterten Sicherheitsmaßnahmen arbeiten, um etwaige Probleme einzudämmen.

Aber auch der SSH-Fehler, der nur im Debianrepository aufgetreten ist (fehlende Entropie hatte die Zahl der generierbaren SSH-Schlüssel auf 65536 limitiert), war nicht ganz ohne, bis zur Entdeckung und Behebung ist damals gefährlich viel Zeit vergangen.

Selbst heute gibt es absurder Weise noch vereinzelte Systeme die dafür anfällig sind. Nur diese sind bei allem Verständnis selbst schuld, wenn man solange nicht aktualisiert bzw. Schlüssel wechselt. Aber das Problem zeigt auch deutlich, dass Kryptographie sehr komplex ist, und das es nicht ausreicht lediglich programmieren zu können. Denn Code kann noch so sauber und technisch fehlerfrei sein, und in kryptographischer Hinsicht dennoch katastrophale Auswirkungen haben.

Versteh mich nicht falsch, ich bin kein Befürworter von Virenscannern. Die Viren, die mich bisher unter Windows angreifen wollten, habe ich mit Brain 1.0 erkannt, wo der installierte Virenscanner noch tagelang ahnungslos war, bevor die Signaturupdates dann doch zu einer Erkennung geführt haben.

Wenn man unter Windows gewisse Regeln beachtet, kann man selbst hier weitestgehend frei von Schädlingen bleiben. Bin aber ohnehin ein Verfechter präventiver Sicherheitsmaßnahmen, da ich wenig Sinn darin sehe hinterher aufzuräumen, wenn das Antivirenprogramm mal wieder versagt hat.

[uname]

Nunja, unter Windows hat es sich allgemein durchgesetzt, daß auf jedem Rechner ein "Wächter" (AKA Virenscanner) läuft, der aufpaßt, daß Schadsoftware sich gar nicht erst einnistet.

Auf dem Client ist der Virenscanner doch nur notwendig, da die Softwarequelle (das ganze Internet) nicht ordentlich gescannt werden kann. Auch Windows versucht auf einen Store zu setzen. Debian und Ubuntu nutzen Repositories und auch Snap Store, Google Play und App Store sind Softwarequellen mit einen beschränkten Umfang von einigen Tausende Softwarepaketen. Somit reicht es wenn der Hersteller (z. B. Google beim Play Store) das Virenscanning durchführt. Niemand braucht einen dezentralen Virenscanner, wenn er nur aus "vertraulichen" Quellen installiert. Der eigene Virenscanner wird immer schlechter sein als die Bemühungen des Store-Betreibers.

[MSfree]

Auf dem Client ist der Virenscanner doch nur notwendig, da die Softwarequelle (das ganze Internet) nicht ordentlich gescannt werden kann.

Schadsoftware kommt ja nicht nur durch willentliches Installieren von Software auf den Rechner. Die meisten Vorfälle kommen doch wohl immer noch per Email. Nun kann man natürlich argumentieren, man solle nicht auf jeden Anhang klicken unf HTML abschalten, im täglichen Leben ist das aber völlig unrealistisch.

Es kommen nunmal auch Rechnungen und Mahnungen auf dem Rechner der Sekretärin an, und diese ist auch angewiesen, sich um Rechnungen und Mahnungen zu kümmern. Der Konflikt aus ich-darf-nicht-auf-Anhänge-klicken und verstreichen lassen der Mahnfrist ist vorprogrammiert.

Auch abschalten von HTML ist unrealistisch. Versuch mal Otto-Nomalverbraucher bezubringen, den Email-Text in HTML-Code zu lesen, oft ist nämlich gar keine ASCII-Version des Textes in der Mail vorhanden. Du wirst auch der Chefetage nicht beibringen können, daß Email form- und formatloses ASCII zu sein hat. In der Geschäftswelt müssen Formalien eingehalten werden, ein Geschäftsbrief hat auch als Email auszusehen wie aus der Textverarbeitung. Sich dagegen zu sträuben, ist ein sinn- und erfolgloses Unterfangen. HTML ist auch nicht gefährlich, gefährlich ist, daß Mailprogramme sinnloserweise Javascript ausführen können und Resourcen wie Bilder und weitere Javascripte aus dem Internet nachladen können. Für die Textformatierung braucht man nämlich kein Javascript und Bilder kann man auch direkt im Mailattachment mitliefern.

Weitere Einfallstore für Schadsoftware sind Datenträger. Wir bekommen hier regelmässig Daten im Umfang von mehreren Terabyte von Kunden. Der schnellste Weg, diese Daten zu übertragen, ist nunmal immer noch eine Festplatte oder bei "kleineren" Datensätzen ein USB-Stick.

Auch Windows versucht auf einen Store zu setzen. Debian und Ubuntu nutzen Repositories und auch Snap Store, Google Play und App Store sind Softwarequellen mit einen beschränkten Umfang von einigen Tausende Softwarepaketen.

Im Google Playstore stehen wohl inzwischen einige Millionen Anwendungen zur Verfügung. Da ständig den Überblick zu behalten, ist mindestens herausvordernd. So ist es auch nicht weiter verwunderlich, daß man fast wöchentlich Meldungen über verseuchte Software lesen kann.

Somit reicht es wenn der Hersteller (z. B. Google beim Play Store) das Virenscanning durchführt.

Was aber bei riesigen App-Stores wohl nur unvollständig passiert.

Niemand braucht einen dezentralen Virenscanner, wenn er nur aus "vertraulichen" Quellen installiert.

Wie gesagt, installieren ist nicht das einzige Einfallstor. und die Naivität der User ist grenzenlos.

Der eigene Virenscanner wird immer schlechter sein als die Bemühungen des Store-Betreibers.

Der Virenscanner beim Shopbetreiber ist nicht auf einem aktuelleren Stand wie der eigene. Der Shopbetreiber hat also keine besseren "Waffen" zur Hand. Umfangreiche Funktionstest von eingereichter Software führen die Shopbetreiber nicht durch.

Selbst Apple macht hier höchstens Stichproben. Die bestehen nur darauf, daß keine von Apple zugelassenen Toolkits zum Einsatz kommen, aber vielmer als die Ausgabe von nm testen die bei neu eingereichter Software auch nicht.

[uname]

Die meisten Vorfälle kommen doch wohl immer noch per Email

Ein ausführbarer E-Mail-Anhang ist für mich vergleichbar mit einen Download von irgendeiner nicht überprüften Internetseite. Der Unterschied ist vielleicht, dass man per E-Mail auf den Schadcode hingewiesen wird und ihn selbst beim Internetsurfen nie gefunden hätte. Somit ist der Schadcode gleich gefährlich aber über E-Mail viel wahrscheinlicher.

man solle nicht auf jeden Anhang klicken

Genau. Die Leute die auf jeden Anhang klicken brauchen einen Virenscanner. Mit Brain 1.0 kann man auf einen Virenscanner fast verzichten. Und ganz schlimm ist wenn Inhalte egal welcher Art automatisch ausgeführt werden.

und HTML abschalten

Würde auch gleich das S/MIME- und PGP-Sicherheits-Problem lösen.

[TomL]

@MSFree

Was mich mal interessieren würde, ist ein Vergleich der Anzahl berechtigter Personen. Wie viel Leute sind grob geschätzt berechtigt, Änderungen am/im Debian-Repo durchzuführen? Wie viel Leute sind ebenso grob geschätzt berechtigt, downloadbare Apps im Google-App-Store zu platzieren? Hast du dafür vielleicht eine Einschätzung, oder meinetwegen auch nur ne begründete Meinung?

Vielleicht lassen sich daraus Ideen über die Anzahl/ Verteilung subversiver Interessen ableiten.

[MSfree]

Wie viel Leute sind grob geschätzt berechtigt, Änderungen am/im Debian-Repo durchzuführen? Wie viel Leute sind ebenso grob geschätzt berechtigt, downloadbare Apps im Google-App-Store zu platzieren? Hast du dafür vielleicht eine Einschätzung, oder meinetwegen auch nur ne begründete Meinung?

Ich habe mir bisher nicht die Mühe gemacht, die Größe des Debian Maintainerteams herauszufinden, die Zahl findet man aber sicher irgendwo, wenn man lange genug danach gräbt. Die Größe des Teams muß aber beträchtlich sein. Es gibt alleine 3 Distros, die noch unter Wartung sind, dazu kommen Testing und SID. In jedem Bereich liegen rund 50000 Softwarepakete für 9 offizielle Architekturen. Das summiert sich auf grob 2.3 Millionen Pakete. Es gibt wohl an die 100 Maintainer, die Pakete in die Repositories stellen dürfen. Bei einer Arbeitslast von 23000 Pakete pro Maintainer kann man sich selbst ausmalen, wie gründlich die Prüfung dabei sein kann. Eine automatisierte Prüfunf ist auch nichts anderes als was ein Virenscanner machen würde, also nicht zuverlässig. Diese 100 sind also wieder von der Zuverlässigkeit anderer abhängig, die die Prüfung stattdessen durchführen. Alles in allem würde ich da schon eine Zahl, die in die paar Tausend geht, für nicht unrealistisch halten.

Beim Google Playstore habe ich gar keine Vorstellung, wie das läuft. Die habe rund 3 Millionen Apps in ihrem Store und wie das Prüfverfahren dort aussieht, weiß ich nicht. Besonders streng scheint es ja nicht zu sein, wenn beim letzten Test von Heise von 100 Taschenlampen-Apps keine einzige sauber war.

[hikaru]

Ich habe mir bisher nicht die Mühe gemacht, die Größe des Debian Maintainerteams herauszufinden, die Zahl findet man aber sicher irgendwo, wenn man lange genug danach gräbt.

Ja, gibt es irgerndwo. Ich weiß nur nicht mehr wo.

Es gibt wohl an die 100 Maintainer, die Pakete in die Repositories stellen dürfen.

Soweit ich mich erinnere, fehlt da eine Null. Ich weiß allerdings nicht mehr, ob die 1000 nur Maintainer oder auch Developer und sonstiges Gedöns waren.

Bei einer Arbeitslast von 23000 Pakete pro Maintainer kann man sich selbst ausmalen, wie gründlich die Prüfung dabei sein kann.

Falls meine Erinnerung richtig ist, dann kannst du hier also eine Null streichen. Aber das verbessert die Sache nur unwesentlich.

Unabhängig davon ist aber fraglich, was diese Metrik taugt. Aus Maintainersicht sind eher Quellcodepakete interessant, man müsste also die betrachten. Wenn im Median ein Quellpaket zu einem Binärpaket wird, dann ändert das natürlich nichts. Wenn aber ein Quellpaket zu 10 Binärpaketen wird, dann ändert das die Sache durchaus. Die Wahrheit liegt vermutlich irgendwo in der Mitte.

Aber auch das ist eigentlich Milchmädchenrechnung, denn Maintainer werden nicht mit der Gießkanne über das Repo verteilt. Manche Pakete kriegen viel Aufmerksamkeit, manche wenig. Es gibt kompetente Maintainer und Inkompetente. Es gibt trivial zu wartende Pakete und nahezu Unbeherrschbare. Auch die Vertrauenswürdigkeit von Upstream variiert je nach Paket.

Vielleicht kann ja Randall Munroe mal einen Diagramm zum Debianrepo mit den Achsen Maintainerkompetenz, Paketkomplexität und Upstreamvertrauenswürdigkeit machen und da dann die Quellpakete einsortieren. Insbesondere die Gegenüberstellung von Firefox und Chromium würde mich hier interessieren.

[MSfree]

[Soweit ich mich erinnere, fehlt da eine Null. Ich weiß allerdings nicht mehr, ob die 1000 nur Maintainer oder auch Developer und sonstiges Gedöns waren.

Die Graphik ganz unten auf dieser Seite zeigt ca. 90 Maintainer:
https://wiki.debian.org/DebianMaintainer
Keine Ahnung, wie aktuell das letztlich ist.

Aber, das sind die Leute, die das Repository befüllen dürfen. Wieviele denen zuarbeiten, geht daraus nicht hervor.

Vielleicht kann ja Randall Munroe mal einen Diagramm zum Debianrepo mit den Achsen Maintainerkompetenz, Paketkomplexität und Upstreamvertrauenswürdigkeit machen und da dann die Quellpakete einsortieren. Insbesondere die Gegenüberstellung von Firefox und Chromium würde mich hier interessieren.

Kannst ihm ja mal 'ne email schreiben

[novalix]

[Soweit ich mich erinnere, fehlt da eine Null. Ich weiß allerdings nicht mehr, ob die 1000 nur Maintainer oder auch Developer und sonstiges Gedöns waren.

Es sind Developer (DD). Die Zahl ist seit etlichen Jahren recht konstant .ca 1000. Debian Maintainer (DM) ist eine vergleichsweise neue Statuskategorie (.ca 10 Jahre alt), die mit weniger Lern- und Prüfungsaufwand erreicht werden kann. In der Umgangssprache sind beide Kategorien "Maintainer".

Die Graphik ganz unten auf dieser Seite zeigt ca. 90 Maintainer:
https://wiki.debian.org/DebianMaintainer
Keine Ahnung, wie aktuell das letztlich ist.

Nicht sehr aktuell, wie Du aus dem Link zum Changelog erlesen kannst.

Aber, das sind die Leute, die das Repository befüllen dürfen. Wieviele denen zuarbeiten, geht daraus nicht hervor.

Das hier ist aktueller und umfassender: https://nm.debian.org/public/stats

Insgesamt ist die Situation, @hikaru hat das ja schon sinnvoll eingeschränkt, weniger dramatisch als Du in Deinem ersten Ansatz überschlagen hast. Das heißt natürlich nicht, dass es keinerlei Probleme (im Sinne von einzelnen Ereignissen) bzw. auch strukturelle Probleme gibt.
Ein wichtiges strukturelles Problem hat @hikaru schon angerissen:
Der Bedarf an gutem Personal ist hoch. Das ist allerdings zum einen nicht so leicht zu finden und zum Anderen auch nicht so leicht einzubinden.
Der DM-Status ist eine bislang recht gut funktionierende Maßnahme, um mehr Leute an das Projekt heranzuführen.
Bei Software-Paketen wie chromium mit seiner reinen Code-Fülle aber auch mit seinem sehr idiomatischen Build-Prozess, könntest Du locker noch fünf zusätzliche Maintainer ins Team hohlen und wärst wahrscheinlich immer noch "unterbesetzt".
Was die Datenintegrität im Debian-Repository im Vergleich zu den App-Stores angeht, liegen da Welten zwischen. Aber das Web of Trust, was Debian versucht aufzubauen und zu implementieren, wird natürlich auch nie "hundertprozentig sicher" sein.

Edith hat noch nen Quote-Fehler rausgelötet.