Forum>Software>Treiber Software von GitHub/SourceForge installieren. Gefährlich???

Treiber Software von GitHub/SourceForge installieren. Gefährlich???

ÄNDY
ÄNDY03.03.2122:10
Hallo liebes Forum-Wissen, hallo liebe MacTech User
Ich möchte für mein MidiSport Interface einen 64-Bit Treiber installieren, der über zum Download bei angeboten wird. So wie ich es verstanden habe kommt eine *.pkg über die dann die Software aus dem Netz geladen und installiert wird.
Ich bin mir nun nicht sicher, ob das seriös ist oder ob ich mir fiese Trojaner, Keylogger und anderes Zeugs damit einfange. Hat jemand Erfahrungen oder Tipps, wie man das gefahrlos ausführen kann.
Ich bin für jeden Hinweis dankbar.
0

Kommentare

almdudi
almdudi03.03.2122:21
Das sind OpenSource-Projekte, bei denen jeder den Code lesen und prüfen kann.
+1
ÄNDY
ÄNDY03.03.2122:27
Danke für den Hinweis. Ja, wenn ich den Code lesen könnte, lesen kann ich ihn vielleicht sogar, doch verstehen und prüfen?? Kann ich eher nicht. ;-(
almdudi
Das sind OpenSource-Projekte, bei denen jeder den Code lesen und prüfen kann.
0
vasquesbc
vasquesbc03.03.2122:59
ÄNDY
lesen kann ich ihn vielleicht sogar, doch verstehen und prüfen?? Kann ich eher nicht. ;-(

OpenSource benötigt ein gewisses Maß an Vertrauen. Wobei das für kommerzielle Produkte eigentlich auch gilt.
„„Nach dem Happy End ging die Story weiter – Nach dem Happy End war sie nicht mehr heiter““
+4
ÄNDY
ÄNDY04.03.2100:37
Ok, ich werde mal ne Nacht drüber schlafen. Vielleicht kommt das Vertrauen. Gibt es da noch jemanden, der schon Erfahrungen mit dem Treiber gesammelt hat?
Ich werde auf jeden Fall berichten, wenn ich alles installiert habe und die Midi-Schnittstelle zum Mac wieder funzt.
vasquesbc
OpenSource benötigt ein gewisses Maß an Vertrauen. Wobei das für kommerzielle Produkte eigentlich auch gilt.
0
sahnehering04.03.2107:13
vasquesbc
OpenSource benötigt ein gewisses Maß an Vertrauen. Wobei das für kommerzielle Produkte eigentlich auch gilt.
Wobei man bei kommerziellen Produkten dem Hersteller vertrauen muss. Bei Open Source Projekten können die unterschiedlichsten Personen/Gruppen die Software überprüfen, und es genügt wenn man einem vertraut (OpenSource Community, große Supporter (google, Apple,...), TÜV, einzelne Programmierer, jemand den man beauftragt, ...)
„Kein Backup, kein Mitleid“
0
almdudi
almdudi04.03.2109:20
ÄNDY
Danke für den Hinweis. Ja, wenn ich den Code lesen könnte, lesen kann ich ihn vielleicht sogar, doch verstehen und prüfen?? Kann ich eher nicht. ;-(
Das kann ich auch nicht.
Aber du kannst dich darauf verlassen, daß es genügend Leute gibt, die das können. Zumindest bei kleineren Projekten. Und da halte ich es für unwahrscheinlich, daß jemand riskiert, da Schadsoftware einzubauen.
Bei anderer software, die du nicht als Code prüfen könntest, ist das Risiko höher.
+5
LoCal
LoCal04.03.2110:36
almdudi
ÄNDY
Danke für den Hinweis. Ja, wenn ich den Code lesen könnte, le
Das kann ich auch nicht.
Aber du kannst dich darauf verlassen, daß es genügend Leute gibt, die das können. Zumindest bei kleineren Projekten. Und da halte ich es für unwahrscheinlich, daß jemand riskiert, da Schadsoftware einzubauen.
Bei anderer software, die du nicht als Code prüfen könntest, ist das Risiko höher.

Da irrst Du dich aber ganz schön, hier ein Beispiel:
Da hat jemand bösen Code in eine sehr beliebte und sehr verbreitete JavaScript-Library gegossen und es hat erstmal niemand gemerkt.

Die Annahme, dass Code sicher sei, nur weil er OpenSource und auf github liegt ist ein Trugschluss!
Wenn es um kritische Dinge geht, sollte man immer selbst prüfen (lassen) und sich nicht auf die Schwarmintelligenz verlassen!
„Ich hab zwar keine Lösung, doch ich bewundere dein Problem“
+1
laancelot04.03.2112:52
Man kann ein System auf einer exterenen SSD installieren, von dort booten und dort das PDK installieren. Mit einem Scanner auf Viren und Malware prüfen. Wenn da nichts gemeldet wird, dann erst auf sein primäres System installieren.
0
Weia
Weia04.03.2113:40
LoCal
almdudi
Bei anderer software, die du nicht als Code prüfen könntest, ist das Risiko höher.
Da irrst Du dich aber ganz schön, hier ein Beispiel:
Ääääähhh, inwiefern kann ein einzelnes Fallbeispiel ein Beleg dafür sein, dass es ein „ganz schöner“ Irrtum sei, dass das Risiko bei Closed-Source-Software höher ist? höher ist eine statistische Relation. Logik 6, setzen.
Da hat jemand bösen Code in eine sehr beliebte und sehr verbreitete JavaScript-Library gegossen und es hat erstmal niemand gemerkt.
Aber dann hat es jemand gemerkt.
Die Annahme, dass Code sicher sei, nur weil er OpenSource und auf github liegt ist ein Trugschluss!
Das behauptet auch niemand. Außer dem Tod ist nichts sicher auf der Welt. Die Annahme lautet, dass der Code sicherer sei als bei Closed Source, und das ist definitiv der Fall. So oder so, ÄNDYs Intuition, er müsse sich vor Open Source mehr fürchten als vor Closed Source, ist nun wirklich völlig verdreht.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
michimaier04.03.2114:43
mal off topic, die midi man dinger gingen doch vor 20 jahren ohne Treiber auf den G3/G4 ... und die gehen nicht mehr auf den aktuellen Rechnern? hätte ich nicht erwartet...
0
LoCal
LoCal04.03.2114:49
Weia
LoCal
almdudi
Bei anderer software, die du nicht als Code prüfen könntest, ist das Risiko höher.
Da irrst Du dich aber ganz schön, hier ein Beispiel:
Ääääähhh, inwiefern kann ein einzelnes Fallbeispiel ein Beleg dafür sein, dass es ein „ganz schöner“ Irrtum sei, dass das Risiko bei Closed-Source-Software höher ist? höher ist eine statistische Relation. Logik 6, setzen.

Ich gebe Dir recht, ich wollte da eigentlich die erste Antwort von almdudi zitieren … mein Fehler!
Aber leider ist es, zumindest im JavaScript-Umfeld, kein Einzelfall … weiter unten mehr dazu.
Weia
Da hat jemand bösen Code in eine sehr beliebte und sehr verbreitete JavaScript-Library gegossen und es hat erstmal niemand gemerkt.
Aber dann hat es jemand gemerkt.

Ja … nur zu spät, der Code war verteilt.
Weia
Die Annahme, dass Code sicher sei, nur weil er OpenSource und auf github liegt ist ein Trugschluss!
Das behauptet auch niemand. Außer dem Tod ist nichts sicher auf der Welt. Die Annahme lautet, dass der Code sicherer sei als bei Closed Source, und das ist definitiv der Fall. So oder so, ÄNDYs Intuition, er müsse sich vor Open Source mehr fürchten als vor Closed Source, ist nun wirklich völlig verdreht.

Da gebe ich dir voll und ganz recht … wie gesagt, ich wollte mich ursprünglich auf die erste Antwort von almdudi beziehen.
Mir ging es bei meiner Antwort auch nicht um "Closed Source ist sicherer als Open Source", was ich auch so nicht vertrete.
Mir ging es um das generelle "Das ist OpenSource und auch github, also kannst Du dem vertrauen" … dieses verhalten halte ich für naiv … auch bei großen, bekannten und/oder weit verbreiteten Projekten.

Und damit komme ich auch zu dem was ich oben noch anfügen wollte.

Ich weiss nicht genau ob es dieser Fall war, auf den sich ein mit mir befreundeter Entwickler bezog, aber zumindest betrifft dieser hier den gleichen Punkt.
Wir hatten es damals über Coocapods & Co und wir sind interessanterweise beide nicht so die Freunde davon.
Bei mir ist es der Kontrollverlust warum ich Cocoapods nicht so mag, beim befreundeten Entwickler ging das tiefer und er hat mir eben von so einem Fall berichtet, als wegen eines Moduls tief in der Dependency Kette mehrere Projekte quasi über Nacht nicht mehr funktionierten.

Wie oben erwähnt, ich bin ein Freund von OpenSource und nutze ja auch selbst OpenSource in Projekten, aber ich finde die Blauäugigkeit mancher Entwickler schon fatal.
„Ich hab zwar keine Lösung, doch ich bewundere dein Problem“
+1
Weia
Weia04.03.2114:50
michimaier
mal off topic, die midi man dinger gingen doch vor 20 jahren ohne Treiber auf den G3/G4 ... und die gehen nicht mehr auf den aktuellen Rechnern?
MIDI-Interfaces, die den generischen USB-MIDI-Treiber nutzen und daher keine eigenen Treiber brauchen, funktionieren jetzt genauso wie vor 20 Jahren (jedenfalls bis Mojave, meines Wissens aber auch bei Catalina und Big Sur nicht anders).

Meiner Erinnerung nach nutzten aber nicht alle M-Audio-Produkte den generischen USB-MIDI-Treiber.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
obri04.03.2115:16
Allgemein: Ich schreibe selbst ausschließlich "open source", allerdings verwende ich gitlab statt github, aber das ist marginal.

Die Gefahr, daß jemand*in Schadcode in ein Projekt injiziert, besteht natürlich immer. Dabei kann der Rechner, auf dem das infizierte Programm gepflegt wird, angegriffen werden, auch durch Paßwort-Diebstahl o.ä., oder die Quelltextdatenbank ist allgemein zugänglich, so daß jede*r darauf rumbraten kann.

Schaust Du Dir das Projekt "leighsmith/midisport-macos" an und gehst auf der github-Seite auf das Uhrensymbol, neben dem "nnn commits" steht, kannst Du sehen, wer wann welche Änderungen gemacht hat. Dort taucht in Deinem Fall nur der Leihschmied selber auf.

Weil github zu Microsoft gehört, könnte man jetzt natürlich vermuten, daß die Melinda-Gates-Stiftung ...

Nein, Quatsch, das Ganze wirkt auf mich seriös. Natürlich ohne Gewähr!
0
ssb
ssb04.03.2115:46
Du kannst auch mit Pacifist anschauen, was als Payload im PKG drin ist und die Dateien dort exportieren und scannen lassen. Auch die Install-Skripte kannst du anschauen.
Angenommen die Code-Basis auf Github ist "sauber", dann könnte es theoretisch noch sein, dass das PKG das nicht mehr ist, sofern es nicht per CI-Build auf Github gebaut wurde. Viele Projekte machen das, aber die Ergebnisse sind dann nicht signiert und notarisiert - was auch wieder fragwürdig ist. Wenn diese aber signiert und notarisiert sind, dann sind diese wieder auf einem Rechner vom Maintainer gebaut worden, weil auf dem auch die notwendigen Zertifikate liegen (in Github würde ich die nicht hinterlegen). Dort könnte er aber AdWare etc. hinzufügen - möglicherweise auch unwissentlich (weil sein System infiziert ist). Es gab auch schon einen Fall, bei dem Xcode aus fragwürdigen Quellen so manipuliert war, dass jedes gebaute Projekt Schadcode enthielt.

Dann bliebe nur, dass Projekt selbst aus Source zu bauen. Dafür gibt es meist auch Anleitungen, aber dennoch ist das nicht für Jedermann geeignet (bzw. umgekehrt). Das hilft auch nur bedingt, wenn man selbst nicht prüfen kann, ob da jetzt Schadcode enthalten ist.
0
gacki04.03.2116:29
Nun ja, das ist ein Treiber für ein relativ einfaches MIDI-Interface - viel Sourcecode ist das nicht. Das kann man eigentlich relativ schnell mal durchlesen; und selbst, wenn man nicht alles versteht, sollte dort sichtbar werden, ob es problematische Dinge gibt, die bewusst eingebaut wurden.
-1
ÄNDY
ÄNDY04.03.2116:47
@allle Herzlichen Dank für die zahlreichen Antworten.
laancelot
Man kann ein System auf einer exterenen SSD installieren, von dort booten und dort das PDK installieren. ...
Das ist ein guter Tipp.
Weia
Meiner Erinnerung nach nutzten aber nicht alle M-Audio-Produkte den generischen USB-MIDI-Treiber.
So ist es bei meinem M-Audio-Produkt.
Ich habe mir den Treiber erst einmal heruntergeladen und werde versuchen, mich noch etwas schlauer zu machen.
0
beanchen04.03.2117:25
vasquesbc
OpenSource benötigt ein gewisses Maß an Vertrauen. Wobei das für kommerzielle Produkte eigentlich auch gilt.
Ja, wenn sogar der ITler den Schadcode beim Kunden platziert: Solarwinds-Hack
0

Kommentieren

Sie müssen sich einloggen, um sich an einer Diskussion beteiligen zu können.