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.

Das sind OpenSource-Projekte, bei denen jeder den Code lesen und prüfen kann.

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. ;-(

OpenSource benötigt ein gewisses Maß an Vertrauen. Wobei das für kommerzielle Produkte eigentlich auch gilt.

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.

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, ...)

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!

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.

Äääää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.
Aber dann hat es jemand gemerkt.
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.

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...

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.

Ja … nur zu spät, der Code war verteilt.

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.

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.

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!

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.

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.

@allle Herzlichen Dank für die zahlreichen Antworten. Das ist ein guter Tipp. 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.

Ja, wenn sogar der ITler den Schadcode beim Kunden platziert: Solarwinds-Hack