Welche Fremdpaketquellen sind safe?

[jstar]

Guten Tag,
mir ist bewusst das Fremdquellen ein Risko sind und man genau prüfen sollte wer hinter den Programmen steht.
Jetzt stellt sich mir die Frage was auf Dauer sicherer ist entweder die klassische .deb Datei installieren mit der Gefahr das man es vergisst bei einer neuen Version erneut zu installieren weil es zu Bugs kam oder über eine unfreie Repo.
Vom Sicherheitsaspekt was sollte man eher tun, Dateien einzeln Installieren über bekannte Repos wie Flatpak oder Snap (kp wie man das unter Debian installiert geht bestimmt auch) oder eine klassische Fremdquellen Repo nehmen in wikis zu lesen dotdeb, deb-multimedia.
Bei der klassischen debian Repo wird ja zum Glück sehr gewissenhaft geprüft und ich denke es gibt im gesamten Internet nur wenig Repos die so safe sind. Ich habe überhaupt keine Ahnung wie Repos im Einzelnen funktionieren wer prüft das, kann jemand fremdes sich für einen Programmierer eines Programms ausgeben obwohl dieser es nicht ist. Also wenn ich im Netz nach Programm xy schaue und dieses durch eine Fremdquelle installieren kann, kann ich mir dann auch sicher sein das das der Original Programm des jeweiligen Programmierers ist?
Wird Flatpak überwacht und wenn von wem?
Snaps wird ja von Canonical verwaltet, jetzt könnte man von Trackern im schlimmsten Fall ausgehen, berechtigt?
Wer verwaltet dotdeb, deb-multimedia.
Ich habe auch schon Arch getestet aber so schön das mit der neusten Software ist wenn man Zuverlässigkeit möchte konnte noch nichts Debian das Wasser reichen außer vielleicht ein BSD aber das ist mir dann wieder zu komplex. Zudem kam es mir vor als ob bei Arch gerade in den User Repos nichts geprüft wird.
Vielen Dank

[cronoik]

Vom Sicherheitsaspekt was sollte man eher tun, Dateien einzeln Installieren über bekannte Repos wie Flatpak oder Snap (kp wie man das unter Debian installiert geht bestimmt auch) oder eine klassische Fremdquellen Repo nehmen in wikis zu lesen dotdeb, deb-multimedia.

Es kommt darauf an wem du vertraust. Eine nicht gewartete oder durch Unfaehigkeit schlechte Fremdquelle ist genauso ein Murks wie diese anderen Paketsysteme wenn die nicht gewartete werden. Die Frage die du dir stellen musst, ist wer die Quelle bereitstellt, ob diese die Quelle auch professionell pflegt und ob du ihr vertraust.

Bei der klassischen debian Repo wird ja zum Glück sehr gewissenhaft geprüft und ich denke es gibt im gesamten Internet nur wenig Repos die so safe sind. Ich habe überhaupt keine Ahnung wie Repos im Einzelnen funktionieren wer prüft das, kann jemand fremdes sich für einen Programmierer eines Programms ausgeben obwohl dieser es nicht ist. Also wenn ich im Netz nach Programm xy schaue und dieses durch eine Fremdquelle installieren kann, kann ich mir dann auch sicher sein das das der Original Programm des jeweiligen Programmierers ist?

Nein. Es haelt mich kein Mensch davon ab ein Repo anzubieten in dem ich einen Firefox zur Verfuegung stelle. Mein Firefox ist uebrigens besonders sicher weil er als root laeuft und ganz neue Kernel-Features verwendet! Das kannst du nur ueberpruefen wenn du den Quellcode vergleichst.

Snaps wird ja von Canonical verwaltet, jetzt könnte man von Trackern im schlimmsten Fall ausgehen, berechtigt?

Ist bis jetzt nicht bekannt und ich weis auch nicht was dieser Generalverdacht gegen Canonical soll. Die Ursachen sind mir schon bekannt (Onlineshop Lense), ich kann es aber im Vergleich zur Leistung von Canonical nicht nachvollziehen.

[wanne]

Jetzt stellt sich mir die Frage was auf Dauer sicherer ist entweder die klassische .deb Datei installieren mit der Gefahr das man es vergisst bei einer neuen Version erneut zu installieren weil es zu Bugs kam oder über eine unfreie Repo.

Im Prinzip ist ein repo immer vorzuziehen. Du bekommst updates und Abhängigkeiten und kannst mit pinning dafür sorgen, dass es keinen Schaden anrichtet.

Also wenn ich im Netz nach Programm xy schaue und dieses durch eine Fremdquelle installieren kann, kann ich mir dann auch sicher sein das das der Original Programm des jeweiligen Programmierers ist?

Nein. apt installiert aber auch keine unvertrauenswürdigen Pakete. Sie müssen einen Signierten Hash haben, der von jemandem kommt, dem du vertraust.
Dazu brauchst du deren öffentlichen Schlüssel. Einige bekannte kannst du aus dem standad Repo holen. z.B. per apt install deb-multimedia-keyring
Andere musst du dir aus anderen wie auch immer vertrauenswürdigen Quellen holen... und kannst sie dann per apt-key add hinzufügen.
Siehe auch: https://wiki.debian.org/DebianRepository/UseThirdParty
Andere Quelle kann ein Download per https sein. Da sollte™ ja jemand den Inhaber überprüft haben. Wenn du mal ein Zertifikat geholt hast weißt du wie gewissenhaft diese Prüfung ist...

Wird Flatpak überwacht und wenn von wem?

Niemand. Flatpak, AppImage und ich glaube auch Snap sind alle halt von den Entwicklern selbst zur Verfügung gestellte Pakete. Der Entwickler entscheidet was rein kommt und da guckt keiner mehr drüber. Deswegen feiern die das so. Sind der Meinung dass sie am besten wissen was für ihre Anwendung gut ist. Ist ein bisschen Glaubensfrage ob man das gut findet oder lieber einen Mittelsmann alla Debian oder RH hat, der da noch mal drüber guckt.

Zudem kam es mir vor als ob bei Arch gerade in den User Repos nichts geprüft wird.

Wie der name Sagt werden die von dem jeweiligen User geprüft. Wie gewissenhaft der das macht hängt vom User ab.

[cronoik]

Im Prinzip ist ein repo immer vorzuziehen. Du bekommst updates und Abhängigkeiten und kannst mit pinning dafür sorgen, dass es keinen Schaden anrichtet.

Das ist kein Unterscheidungsmerkmal. Updates und pinning hast du zumindest bei snap auch (die anderen Systeme wahrscheinlich aehnlich). Abhaengigkeiten kommen ja gleich mit. Beide Systeme haben ihre jeweiligen Vor- und Nachteile und sollten entsprechend dem Anforderungen eingesetzt werden.

[Ibex]

Im Prinzip ist ein repo immer vorzuziehen. Du bekommst updates und Abhängigkeiten und kannst mit pinning dafür sorgen, dass es keinen Schaden anrichtet.

Das gilt aber nur, wenn man sich auch wirklich mit pinning auseinandersetz und für die jeweilige Quelle sinnvolle Regeln festlegt. Die Praxis dürfte eher sein, dass einfach nur die Fremdquelle eingetragen wird. Und dann kann über die Fremdquelle theoretische jede Systemdatei aktualisiert werden, in dem einfach eine Version mit höherer Nummer bereitgestellt wird. Wenn man einfach nur ein einzelnes Paket benötigt, kann es daher sicherer sein, nur das .deb herunterzuladen, oder die Fremdquelle gleich nach der Installation wieder auszukommentieren, und sich selbst um Updates zu kümmern.

[fischig]

Welche Fremdpaketquellen sind safe?

Ich denke, es existiert keine „safe“ Anwort zu dieser „Grundsatz“frage, die den TE sowieso nicht besonders zu interessieren scheint.

[Blackbox]

Aus meiner Sicht können Fremdquellen nicht "safe" sein, da sie weder vom Debian Projekt, noch vom Debian Security Team geprüft werden.
Außerdem ist es fraglich, ob Fremdquellen-Anbieter überhaupt die Softwarekompatibilität testen?

[mcb]

Im Prinzip ist ein repo immer vorzuziehen. Du bekommst updates und Abhängigkeiten und kannst mit pinning dafür sorgen, dass es keinen Schaden anrichtet.

..................... Wenn man einfach nur ein einzelnes Paket benötigt, kann es daher sicherer sein, nur das .deb herunterzuladen, oder die Fremdquelle gleich nach der Installation wieder auszukommentieren, und sich selbst um Updates zu kümmern.

Da ist natürlich was dran. Werde ich wohl so umsetzen.

Wie sicher schätzt ihr den folgende Fremdquellen ein:

Microsoft (ja ich weiß) -> Powershell Core
Google (...) -> Chrome
VS Codium (github)

[Blackbox]

Microsoft (ja ich weiß) -> Powershell Core
Google (...) -> Chrome
VS Codium (github)

Da du völlig schmerzbefreit zu sein scheinst und dich auch nicht wirklich davon abbringen lassen möchtest, diesen vergleichsweise unsympathischen bzw. nicht vertrauenswürdigen Unternehmen dein Vertrauen zu schenken, solltest du nicht die Erwartungshaltung besitzen, dass es bei Problemen einen Full Support geben kann.

Ich gebe weiterhin zu bedenken, dass man nicht alles machen sollte was von Dritten ermöglicht wird.

Warum möchtest du beispielsweise keinen chromium verwenden?
Dieser Browser ist zumindest nicht proprietär, du könntest ihn aus dem Debian Repository beziehen, ohne extra dafür eine Fremdquelle einfügen zu müssen.
Hoffentlich ist dir auch bekannt, dass VSCode/VSCodium Telemetriedaten erfasst und an Microsoft sendet.
Was spricht eigentlich gegen beispielsweise geany als Entwicklungsumgebung?

[Animefreak79]

Zudem kam es mir vor als ob bei Arch gerade in den User Repos nichts geprüft wird.

Und wer garantiert dir jetzt, dass eine Debian zusammengeschnürte und in ein .deb-Paket verpackte Fremdquelle XYZ zuverlässig geprüft wird, außer dessen Hersteller? Hier im Forum würde vermutlich niemand (nein, ich meine jetzt nicht den User gleichen Namens hier) dir diese Garantie geben können.

Microsoft (ja ich weiß) -> Powershell Core
Google (...) -> Chrome

Unter Debian hast du die bash oder wahlweise auch andere Shells wie etwa csh (also die C-Shell) wie auch zsh (Z-Shell)... Für welchen Zweck man unter diesen Umständen die Powershell braucht, erschließt sich mir nicht. Und dann...

Warum möchtest du beispielsweise keinen chromium verwenden?
Dieser Browser ist zumindest nicht proprietär, du könntest ihn aus dem Debian Repository beziehen, ohne extra dafür eine Fremdquelle einfügen zu müssen.

Eben. Auch wenn es mit dem aktuellen chromium für Debian derzeit offenbar ein paar Probs gibt (kA, ob dies jetzt auch den unfreien Google-Browser betrifft), ist es immer eine weisere Entscheidung, wenn möglich aus den Original-Repos zu installieren. Der mit größte Vorteil von Debian liegt ja gerade in dem umfangreichen Repository und dessen "Alles-aus-einer-Hand-Natur", weshalb es mir schleierhaft ist, wieso man sich diesen Vorteil durch irgendwelche Fremdquellen direkt wieder zunichte macht.

[mcb]

Zudem kam es mir vor als ob bei Arch gerade in den User Repos nichts geprüft wird.

Und wer garantiert dir jetzt, dass eine Debian zusammengeschnürte und in ein .deb-Paket verpackte Fremdquelle XYZ zuverlässig geprüft wird, außer dessen Hersteller? Hier im Forum würde vermutlich niemand (nein, ich meine jetzt nicht den User gleichen Namens hier) dir diese Garantie geben können.

Microsoft (ja ich weiß) -> Powershell Core
Google (...) -> Chrome

Unter Debian hast du die bash oder wahlweise auch andere Shells wie etwa csh (also die C-Shell) wie auch zsh (Z-Shell)... Für welchen Zweck man unter diesen Umständen die Powershell braucht, erschließt sich mir nicht. Und dann...

Warum möchtest du beispielsweise keinen chromium verwenden?
Dieser Browser ist zumindest nicht proprietär, du könntest ihn aus dem Debian Repository beziehen, ohne extra dafür eine Fremdquelle einfügen zu müssen.

Eben. Auch wenn es mit dem aktuellen chromium für Debian derzeit offenbar ein paar Probs gibt (kA, ob dies jetzt auch den unfreien Google-Browser betrifft), ist es immer eine weisere Entscheidung, wenn möglich aus den Original-Repos zu installieren. Der mit größte Vorteil von Debian liegt ja gerade in dem umfangreichen Repository und dessen "Alles-aus-einer-Hand-Natur", weshalb es mir schleierhaft ist, wieso man sich diesen Vorteil durch irgendwelche Fremdquellen direkt wieder zunichte macht.

Gut kurz vorweg ich bin "Anfänger", aber nicht schmerzfrei.

Mir ging es bei meiner Frage mehr darum ob die "gut" gewartet werden (die Fremdquellen) -> das traue ich Google und MS im Grunde schon zu.

VS Codium wird ja im Debian-Wiki auch aufgelistet:

https://wiki.debian.org/VisualStudioCode

Visual Studio Code ohne Telemetrie; so verstehe ich das mit OpenSource -> Jemand verändert den Quellcode und nimmt in diesem Fall die Telemetrie raus und ich kann mich entscheiden. Muß dem Programmierer natürlich vertrauen,

Chrome oder Chromium beides nicht meine erste Wahl (Firefox). Chromium bei Buster hängt bei den Sicherheitsupdates aber nicht nur ein paar Tage zurück. Selber patchen oder kompilieren kann ich den nicht ...

Und ja nach Möglichkeit nehme ich die bash oder Codeblocks. So brauche ich wenigstes keinen Dualboot.

[mcb]

Microsoft (ja ich weiß) -> Powershell Core
Google (...) -> Chrome
VS Codium (github)

...........................solltest du nicht die Erwartungshaltung besitzen, dass es bei Problemen einen Full Support geben kann.

Ich gebe weiterhin zu bedenken, dass man nicht alles machen sollte was von Dritten ermöglicht wird.

............................

Nein die Erwartungshaltung habe ich nicht. Wenn ich mir mit Fremdsoftware das System zerschieße erwarte ich selbstverständlich keinen "Full"-Support. Der Chromium ist mir zu "veraltel". (Momentan hat er den gl. Patchstand wie Chrome, in der Regel aber nicht).

[Blackbox]

Der Chromium ist mir zu "veraltel". (Momentan hat er den gl. Patchstand wie Chrome, in der Regel aber nicht).

Ich weiß nicht, wie du zu dieser Behauptung kommst, aber der chromium Bug Tracker [0] belegt, dass du im Unecht bist.

[0] https://security-tracker.debian.org/tracker/chromium

[mcb]

Ja ich habe doch geschrieben im Moment ist der Patchlevel gleich. Das war in den letzten 6 Monaten nicht immer der Fall (ehr im Gegenteil).

[Blackbox]

Ja ich habe doch geschrieben im Moment ist der Patchlevel gleich. Das war in den letzten 6 Monaten nicht immer der Fall (ehr im Gegenteil).

Und ich habe mit einer Quelle belegt, dass dich dein Gefühl trügt.

[TomL]

Mir ging es bei meiner Frage mehr darum ob die "gut" gewartet werden (die Fremdquellen) -> das traue ich Google und MS im Grunde schon zu.

Darauf kannst Du Dich sogar ganz sicher verlassen... ich wette auch darauf, dass die ihre aktuelle Software gewissenhaft warten. Nur hat eben genau das gar nichts mit "safe" zu tun. Wenn eine solche Software unerlaubte Dinge im Verborgenen tut, die nicht in Deinem Sinne sind, so kann das durchaus genau dem Unternehmensziel und dem Zweck dieser Software entsprechen ... soll heißen, das Programm tut, zu was es von ms oder google beauftragt ist. Bei google und ms kann man das zweifelsfrei unterstellen, weil die Daten Deines Lebens eben ein gewinnträchtiger Rohstoff sind und solche Unternehmen damit ihre Kohle verdienen. Fazit: solche Software ist das Gegenteil von "safe".

[mcb]

O.k. was haltet ihr von Veracrypt ? Darf ich denen trauen ?

[Blackbox]

was haltet ihr von Veracrypt ? Darf ich denen trauen ?

Warum willst du denen trauen?
Es gibt cryptsetup.

[mcb]

was haltet ihr von Veracrypt ? Darf ich denen trauen ?

Warum willst du denen trauen?
Es gibt cryptsetup.

Das kenne ich jetzt nur im Zusammenhang mit LUKS - kann man damit auch veracrypt Container einbinden - dann bräuchte ich das wirklich nicht (die haben auch kein Repro)

- je länger ich drüber nachdenke: Verstehe ich das richtig das ein Hauptproblem der Fremdquellen ist, daß darüber andere Pakete ausgetauscht werden können / könnten ??? (Absichtlich oder unabsichtlich)

[DeletedUserReAsG]

Verstehe ich das richtig das ein Hauptproblem der Fremdquellen ist, daß darüber andere Pakete ausgetauscht werden können / könnten?¹

Aus sicherheitstechnischer Sicht könnte man die Tatsache, dass man dem Betreiber des Repos Rootrechte auf seinem System einräumt, als Hauptproblem sehen. Neben natürlich möglicherweise nachlässigem Umgang mit gefundenen Sicherheitslücken in der paketierten Software selbst.

Aus Sicht der Betriebssicherheit würde ich als problematisch ansehen, dass die Pakete nicht mit dem restlichen System syncron sind: gibt’s da ein Update, können möglicherweise Abhängigkeiten nicht mehr erfüllt werden. Das ist ganz besonders toll, wenn Pakete aus einer Fremdquelle von denen aus einer anderen Fremdquelle abhängig sind, oder man recht viele Sachen aus Fremdquellen nutzt, oder sich von den Sachen aus den Fremdquellen abhängig gemacht hat. Fährt man Stable, kommt erschwerend hinzu, dass sich die Probleme seit letztem Releasewechsel kumulieren, und dann alle auf einmal zutage treten. Außerdem möglicherweise problematisch sind hier nachlässig gebaute Software und nachlässig gepackte Pakete.

Aus sozialer Sicht: während das Debianprojekt ’nen ziemlich guten Ruf hat, den sich die Leute über Jahrzehnte aufgebaut und gepflegt haben, und wo sie alles dransetzen werden, den nicht auf einem Schlag kaputtzumachen, muss sich ein Betreiber eines eigenen Repos, möglicherweise gar nur für ein Programm, da weniger Sorgen machen: er müsste schlimmstenfalls hinnehmen, dass seine paar User abspringen, nachdem sie ihm ’nen bitterbösen Post auf seiner Foobookseite hinterlassen haben.

¹) entplenkt

[mcb]

Ja Danke jetzt habe ich das begriffen.

Aus dieser Perspektive ist es also sicherer:

- die Fremdprogramme als tar zu laden und dann nach /opt zu entpacken.
- selbst zu kompilieren
- oder zumindest die automatischen updates über die Fremdquellen auszukommentieren.

In allen drei Fällen muß ich dem Programmierer natürlich vertrauen (mal mehr mal weniger). Schwierig.

Jetzt sieht es so aus:

Code: Alles auswählen

marc@mb:~/glmark2$ aptitude search '~i!?origin(debian)';aptitude search '~i ?origin(Microsoft)'
i   veracrypt                                    - Disk encryption with strong security based on TrueCryp

Code: Alles auswählen

&& sudo apt autoremove -y
Hit:1 http://deb.debian.org/debian buster InRelease
Hit:2 http://deb.debian.org/debian buster-updates InRelease           
Hit:3 http://security.debian.org/debian-security buster/updates InRelease
Hit:4 http://deb.debian.org/debian buster-backports InRelease         
Hit:5 http://cdn-fastly.deb.debian.org/debian buster-backports InRelease
Reading package lists... Done
Building dependency tree       
Reading state information... Done
3 packages can be upgraded. Run 'apt list --upgradable' to see them.

[mcb]

Flatpak, Wine oder Snap sind auch nicht der Weisheit letzter Schluß oder ?

Nach Virtual-Box frage ich besser gar nicht ... das war mir schon zu heikel.

[Animefreak79]

Aus dieser Perspektive ist es also sicherer:

- die Fremdprogramme als tar zu laden und dann nach /opt zu entpacken.
- selbst zu kompilieren

In beiden Fällen würdest du an der Paketverwaltung vorbei agieren. dpkg kann die derart eingerichtete Software, dessen Libraries uswusf nicht erfassen, apt oder aptitude wären demzufolge ebenfalls komplett aus dem Rennen, du müsstest dich im Bezug auf die Fremdprogramme auch selbst um die Abhängigkeiten kümmern und würdest die auf diese Art eingerichtete Software auch nur unter ziemlichen Schwierigkeiten vom System wieder runter bekommen. Die Gefahr, sich mit diesem Vorgehen ein eher inkonsistentes System einzuhandeln, ist so definitiv gegeben!

Flatpak, Wine oder Snap sind auch nicht der Weisheit letzter Schluß oder ?

Es sind mögliche Lösungen, aber sicher nicht die Besten... Aber immer noch besser, als tar-Archive selbst an der Debian-Paketverwaltung vorbei zu entpacken, oder mittels

Code: Alles auswählen

./configure

Code: Alles auswählen

make

und

Code: Alles auswählen

make install

den Quellcode selber zu übersetzen, in der Hoffnung, dass dabei kein Fehler auftritt... Do sulltest dir aber darüber im Klaren sein, dass sowohl flatpak (welches ich von den 3 von dir genannten Kandidaten noch am ehesten nutzen würde), als auch wine wie auch Snap nur Notlösungen sind, auf die man erst dann zugreifen sollte, wenn es tatsächlich absolut keine brauchbare Alternative gibt.

Nach Virtual-Box frage ich besser gar nicht ... das war mir schon zu heikel.

War bei Stretch zumindest mal in den Backports, bei Buster gibt es das meines Wissens nach nicht mehr in den offiziellen Quellen. Habe es eine Zeit lang benutzt, ist aber schon 'ne Weile her und auch nicht immer die performanteste Lösung. Letztendlich kommt es halt immer darauf an, was du machen willst und welche Lösung für dich am Optimalsten scheint.

[mcb]

Ah Danke.

Ideal ist das alles nicht, aber ich kann ja nicht für jedes Programm das ich für toll halte einen Maintainer fordern. (Selbst kann ich das nicht, zu wenig Programmierkentnisse).

Darf man Vorschläge einreichen, wenn ja wo ?

Und bei Debian ist auch vieles neu für mich.

[wanne]

Das kenne ich jetzt nur im Zusammenhang mit LUKS - kann man damit auch veracrypt Container einbinden - dann bräuchte ich das wirklich nicht (die haben auch kein Repro)

Die meisten. Nicht alle. Z.B. kann cryptsetup keine doppelt verschlüsselten.
Edit: Versteckte Partitionen sind nun supported. Meine Info war veraltet.