Hallo,

ich bin zu limitiert, um das selbst zu machen, daher frage ich, ob hier jemand so freundlich wäre und mir den Quellcode der aktuellen rsync in eine Ausführbare Unix-Datei kompilieren kann, damit ich diese auf meinem M1 nutzen kann. Den Quellcode gibts hier https://rsync.samba.org

Beste Grüße
Tobias

PS. Homebrew und Co ist für mich keine Alternative.

Nimm doch Homebrew und installier dir dort dann das fertige Paket.

Gerade probiert es wird 3.2.7 installiert auf meinem MBA M1

Hi Lumi,

ich hätte gerne eine Lösung ohne Homebrew, daher meine Frage, ob sich hier jemand nettes findet.

Beste Grüße
Tobias

Mal eben was compilieren, ist glaube ich nicht ganz so einfach. Manchmal gibt es noch Abhängigkeiten von anderen Frameworks oder Bibliotheken. Das müsste der nette Mensch, auch noch an Arbeit investieren. Dazu kommt dann auch die fehlende Notarisierung bzw. Signierung.
Was ich nun nicht weiß ist, ob eine solche Anwendung auf einem anderen Mac garnicht läuft, oder ob man diese mit einem RechtsklickÖffnen doch starten kann.

Vielleicht findet sich ja jemand. Bei mir scheitert es daran, dass ich keinen M1 habe. Dagegen stehen 5min um es mit Homebrew selbst zu erledigen.

Hi Karsten,

ok, dann habe ich das falsch eingeschätzt -- sowohl den Aufwand, als auch die technische Herausforderung. Die 5 Minuten Homebrew werde ich vermutlich nicht schaffen ... Ich gucke ...

Danke für die Info.

Gruß, Tobias

Ich weiß ja nicht was genau die gewünschte Anwendung ist, aber vielleicht funktioniert auch freefilesync für Deine Zwecke

Das kann ja eigentlich nicht sein, unter Gentoo benoetige ich keine 2 Minuten und dann ist das Teil fertig kompiliert, rsync ist ja nun wirklich keine grosse Anwendung und auf dem Mac soll das in eine zeitaufwaendige Raketenwissenschaft ausarten.
Habe mir unter Gentoo gerade mal das ebuild angesehen, es hat keine build dependencies, es sind ein paar Abhaengigkeiten hauptsaechlich in Richtung openssl und lz4 / zstd fuer die compression vorhanden, diese werden aber auch nur dann benoetigt, wenn man dies in der Config auch aktiviert, es sollte sich aber auch pur ohne den ganzen Plunder uebersetzen lassen, sofern man darauf verzichten kann.

Ich habe jetzt keinen M1 mit Xcode hier sonst haette ich es mal versucht, so schwer kann das ja nicht sein,
solange man zunaechst mal alle moeglichen Abhaengigkeiten (viele sind es ja nicht, vor allem halt openssl) in der config deaktiviert.

Tobias: Wäre Homebrew eventuell nicht doch die beste Möglichkeit für Dich?

Bitte nicht als Vorwurf oder Kritik missverstehen – ich möchte Dir lediglich virtuell unter die Arme greifen und Dich ermutigen, den einzelnen Schritten zu folgen.

In der Terminal.app folgendes machen:


So wird erst einmal 'Homebrew' inklusive der 'Command Line Tools for Xcode' installiert, das dauert knapp 2-3 Minuten.

Wenn Du nicht möchtest, dass Homebrew 'nach Hause telefoniert' (mit Analyse-Daten), dann als nächsten Schritt einfach


ausführen.

Anmerkung: Ausführlich erläutert werden diese "anonymous aggregate formulae and cask analytics" hier:



Die wichtigsten Befehle, die man kennen sollte sind:


und natürlich


Wobei speziell für Dich dann:


von Interesse sein dürfte.

rsync ist dann die aktuelle Version 3.2.7:


PS: Und am Ende freuen sich die Entwickler von Homebrew natürlich über eine kleine Spende.

Zur Anwendung: Ich brauche ein aktuelleres rsync, als die alte 2er Version, die Ventura mitbringt, um von einem Synology ein Backup via Hyper Backup auf einen M1-Mac zu machen. Das funktioniert mit einem alten Mac mini (dank dieses Forums) schon, allerdings wird der Mini jetzt gegen einen neuen Mac getauscht. Damals habe ich mir eine aktuellere rsync-Version aus dem Tool rsync server Basic Edition genommen. Das wird aber offensichtlich nicht weiter gepflegt.

Terminal und Co sind einfach nicht meine Welt.

@Frost: Danke, dass Du Dir die Zeit genommen hast. Schade, dass Du keinen M1 hast

Hi Marcel,

vielen Dank für die Anleitung. Ich werde das wohl morgen mal testen, wenn ich den M1 griffbereit habe.

Gruß, Tobias

PS. Habs gerade 2x gelesen, kann aber weder Vorwurf, noch Kritik finden

Dir ist der Synology Hyper Backup Explorer bekannt?
Ein Desktop-Tool zum Durchsuchen, Entschlüsseln und Extrahieren verschiedener Versionen von Sicherungsdaten in Hyper Backup-Repositories.

Hallo marm,

nein, der ist mir nicht bekannt. Aber ich will doch erstmal ein Backup erstellen. Das Tool könnte ich doch erst nutzen, wenn ich ein Backup erstellt habe, oder Blicke ich es gerade nicht?

Tobias

Ach so. Ein "Backup auf einen M1-Mac" klang für mich, als wolltest Du auf alte Dateien zurückgreifen.

Dann hab ich mich missverständlich ausgedrückt. Ich Schaufel vom Synology via Hyper Backup ein Backup auf den Mac. Dafür brauchts ein aktuelles rsync (3.x, glaube ich).

Naja, Du hast in Deinem Ausgangs-Post ja explizit darauf hingewiesen, dass Homebrew eigentlich keine sinnvolle Option für Dich ist – und dann komme ich Dir mit der Homebrew-Nummer und 'Terminal-Vodoo'…

Also probiere es ruhig mal aus, denn es ist gar nicht so kompliziert wie Du vllt. denkst.

OK, aber Vorwurf und Kritik geht schon noch anders. Das musste noch mal üben
Danke, werde es mal testen.

Ja, aber in aller Regel hat man die fraglichen Bibliotheken eh installiert, wenn man sowas macht. Es gibt vertrackte Ausnahmen, aber in der Regel ist das in ein paar Minuten erledigt. Ich kann kann nur nichts für den M1 kompilieren, sonst hätte ich das gemacht.
Die gibt es auf der Unix-Ebene nicht, nur bei bei GUI-Apps.
Wie gesagt, dieses Problem existiert nicht.
Es gibt aber sehr gute Gründe, Homebrew zu meiden, weil es parallel zu einer existierenden und funktionierenden Unix-Hierarchie sein eigenes Süppchen kocht.

Jemandem, der nicht genau einschätzen kann, was er sich da verkonfiguriert, Homebrew zu empfehlen, ist aber gar keine gute Idee.

Eben.

Für jemanden, der weiß, wie sowas im Prinzip geht, ist das nullomanix erledigt. Es ist völlig over the top, sich deswegen Homebrew aufzuhalsen.
Auch mit SSL geht es völlig problemlos und dauert 2, 3 Minuten; ich hab’s vorhin auf Intel probiert.

Gibt es denn niemanden auf MacTechNews, der einen M1 besitzt und zu so einer Kompilation imstande ist, statt auf das Homebrew-Ungetüm auszuweichen???

Mmh, also ich halte Homebrew für eher unproblematisch, denn das originale zum System gehörende rsync (also das /usr/bin/rsync) bleibt ja bei der alten Version 2.6.9 (also komplett unberührt) und die von Homebrew verwendete neuere Version 3.2.7 ist /usr/local/bin/rsync – die kommen sich doch also gar nicht in die Quere?

Und da man seit DSM 7 für HyperBackup die neuere Version 3.x.x von rsync benötigt, ist das doch eine sinnvolle Option?

Aber ich gebe Dir recht – eine direkt für 'Apple Silicon' kompilierte Version des aktuellen rsync 3.2.7 wäre natürlich 'schlanker'.

@Marcel_75@work

Weia geht es um die Veränderung von Ordnerberechtigungen. Das wurde schon einmal ausführlich diskutiert.

Also, ich hab' mir gerade gedacht, ich opfere mal 3min - kann ja nicht so schwer sein. rsync-src geladen, ./configure aufgerufen, dann kam die Meldung:
… und da waren dann schon 2min rum und ich hatte anstelle von einem gelösten Problem vier neue.

Ich denke auch, homebrew ist die beste Lösung.

Ah, OK, danke für die Info. Ich habe alle diese Libraries eh installiert, weil ich sowas öfters mache, deshalb habe ich das gar nicht bemerkt.
Vier neue hat man, wenn man auf diese Features nicht verzichten kann; das weiß ich jetzt bei Tobias natürlich nicht. Wenn man das kann, kann man einfach die vier erwähnten Optionen angeben und die Kompilation läuft durch.

Besser ist aber natürlich mit den Features. Wie gesagt, wenn man sowas öfters und mit ähnlichen Programmen macht, hat man die OpenSSL-Libraries etc. eh bereits installiert und das ist alles kein Problem.

Ich sehe aber ein, dass es eine Fleißaufgabe ist, wenn man die ganzen Abhängigkeiten auch erst noch installieren muss.

Ab M1 ist dies das Verzeichnis /opt/homebrew/bin/rsync

und hier bei M1:
/opt/homebrew/Cellar/rsync/3.2.7/bin/rsync

In dem besagten Thread, bei dem viel über mangelnde Sicherheit von homebrew diskutiert wurde, ging es vor allem um die Rechte vom /usr/local/-Verzeichnis.
Hat sich das Thema bei Apple Silicon damit erledigt?

Darauf hatte ich ja schon in meinem Posting oben hingewiesen, es gibt ein paar Abhaengigkeiten aber keine Buildkritischen. Das bedeutet wie configure es bereits ausgibt kann man diese zunaechst ueber das Setzen der entsprechenden vier commandline Parameter abschalten. Anschliessend muesste configure eigentlich ohne Abhaengigkeitsfehler durchlaufen. Wenn man die entsprechenden Funktionen aber nutzen moechte, muss man natuerlich die aufgefuehrten Bibliotheken vorher erst kompilieren. Einen ersten Erfolg sollte man aber mit den commandline Parametern fuer das Deaktivieren der Funktionen auch ohne die Bibliotheken wie z.B. openssl bekommen.
Das ist halt des schoene z.B. an den Gentoo ebuild, auch wenn ich etwas lokal in meinem Userhome kompiliere da ich keinen vollen Systemzugriff habe und emerge nicht nutzen kann, zeigt mir ein Blick in das ebuild sofort mit welchen Abhaengigkeiten ich beim Compilieren der Anwendung rechnen muss und auch alle buildkritischen Abhaengigkeiten (also alles was sich nicht durch Konfigurationsparameter abschalten laesst und zum erfolgreichen Kompilieren benoetigt wird ist sofort sichtbar) leider schweigen sich naemlich doch oefters die Dokus zu den entsprechenden Anwendungen, ueber die benoetigten Voraussetzungen fuer einen erfolgreichen Kompilerdurchlauf, aus.

Nö. Dann damit die Homebrew-Programme auch vom Terminal gefunden werden, musst Du deren Pfad ja in die PATH-Variable aufnehmen und zwar vor den anderen Pfaden, sonst würde ja das rsync aus denen genutzt. Und damit hat sich diesbezüglich gar nichts geändert.

Der entscheidende Faktor bleibt, ob ein Nicht-root-Nutzer in den fraglichen Homebrew-Ordnern – welche immer das sind – aus Bequemlichkeitsgründen bei der Installation Schreibrechte hat. Hat er die nach wie vor, ist Homebrew nach wie vor eine riesige Sicherheitslücke, denn dann kann ein Schadprogramm, das sich der Nutzer in seinem Nutzerkonto einfängt, nach wie vor unbemerkt und problemlos z.B. das echte rsync gegen ein ganz anderes, gleichnamiges Programm ersetzen, das danach sonstwas tut, wenn es aufgerufen wird.

Mal jemand zu lesen der in diesem Punkt auch meiner Meinug ist.
Genau das sage ich den Wissenschaftlern hier auch immer (wenn es mal wieder um den Punkt Unix Tools geht), tut euch doch nicht dieses Monstrum im System an, wenn ihr nur schnell mal ein paar kleine Unix Tools auf euren Macs benoetigt.

Ich wuerde es ja noch verstehen, wenn es dann um Programme wie den Firefox oder den Rust Compiler, um mal zwei Monsteranwendungen zu nennen, gehen wuerde, da kann ich ja noch nachvollziehen wenn da keiner Bock drauf hat so etwas stundenlang kompilieren zu wollen, plus sich erst einmal die ganzen Tools zusammen zu suchen damit der Build ueberhaupt erst moeglich ist aber bei so kleinen ueberschaubaren Anwendungen von denen es im Unix Bereich hunderte gibt, ist das dann wie mit Kanonen auf Spatzen.

Vielen Dank erstmal für den Austausch hier und die Zeit, die ihr in meine Frage investiert. Ich nehme einiges an Infos mit und kann zumindest abwägen, welche Lösung mir die Liebste wäre. Im Moment hoffe ich, ohne Homebrew auskommen zu können. wicki hat den richtigen Rechner, aber nicht alle Libraries installiert – weia hat alles installiert, aber nicht den richtigen Rechner. Wollt ihr euch nicht mal treffen

Nur aus Interesse: Wenn jemand auf einem M1 rsync 3.x via Homebrew installiert hätte, würde mir die Ausführbare Unix-Datei weiterhelfen?

Nein Tobias, do brauchst auch alle libraries, da home-brew keine static linked tools erstellt (alle libraries in dein rsync reinpackt), wird die ganze home-brew Umgebung benötigt (so wie bei linux auch).

Ich hallte home-brew für die einfachste Variante es selbst auf dem aktuellen Stand zu halten.

Für rsync 3.2.4 hab ich den build auf M1 mal selbst gemacht ist nicht schwer aber schon aufwendig (für 3.2.7 empfehle ich überall die aktuellen libraries zu generieren insbesondere bei OpenSSL):

mkdir ~/rsync;
cd ~/rsync;
curl -OL https://github.com/Cyan4973/xxHash/archive/v0.8.0.tar.gz;
tar -xvf v0.8.0.tar.gz;
rm v0.8.0.tar.gz;
cd xxHash-0.8.0;
make -j4;
sudo make install;
cd ~/rsync;
curl -OL https://github.com/lz4/lz4/archive/v1.9.3.tar.gz;
tar -xvf v1.9.3.tar.gz;
rm v1.9.3.tar.gz;
cd lz4-1.9.3;
make -j4;
sudo make install;
cd ~/rsync;
curl -OL https://www.openssl.org/source/openssl-1.1.1k.tar.gz;
tar -xvf openssl-1.1.1k.tar.gz;
rm openssl-1.1.1k.tar.gz;
cd openssl-1.1.1k ;
./config;
make -j4;
sudo make install;
cd ~/rsync;
curl -OL https://github.com/facebook/zstd/archive/v1.5.0.tar.gz;
tar -xvf v1.5.0.tar.gz;
rm v1.5.0.tar.gz;
cd zstd-1.5.0 ;
make -j4;
sudo make install;
cd ~/rsync;
curl -OL https://rsync.samba.org/ftp/rsync/src/rsync-3.2.4.tar.gz;
tar -xvf rsync-3.2.4.tar.gz;
rm rsync-3.2.4.tar.gz;
curl -O https://rsync.samba.org/ftp/rsync/src/rsync-patches-3.2.4.tar.gz;
tar -xzvf rsync-patches-3.2.4.tar.gz;
rm rsync-patches-3.2.4.tar.gz;
patch -p1 <patches/fileflags.diff;
cd rsync-3.2.4;
./configure;
make -j4;
sudo make install;
/usr/local/bin/rsync --version;

Wenn homebrew das kann, dann kann das jedes Schadprogramm auch ganz ohne homebrews Hilfe. Die Lücke ist also nicht Homebrew sondern die Unix Architektur.

Nein, das kann man so nicht stehen lassen. Homebrew kann nur von einem Administrator eingerichtet werden. Bei der Einrichtung wird das Kennwort des Administrators abgefragt. Mithilfe der so erlangten Privilegien werden dann Berechtigungseinstellungen für Betriebssystemordner so verändert, dass sich danach "für immer" Sicherheitslücken ergeben. Aus diesem Grund ist der Einsatz von Homebrew problematisch.

Man braucht nur einem Mac mit aktuellem Betriebssystem und Xcode. Welchen Prozessor der hat, ist völlig egal. Damit das Programm für Apple Silicon erzeugt wird, muss man im Prinzip nur den Eintrag "-arch arm64" zu den CFLAGS hinzufügen.

Ich war in der gleichen Lage und homebrew befindet sich bei mir auf anderen 'Planeten.
Und wer sucht der findet: einen aktuelleren binary-installer!
https://github.com/chris1111/rsync-3.1.3-macOS-Package/releases

Leider noch nicht M1- aber auf macOS 11.7 funktioniert die Version 3.1.3 wunderbar.
direkt installieren und System-Preferences, Security dann freigeben.
Es überschreibt die 2er Version und die 3.1er ist schon mal was (2018), der Chris ist in der kanadischen Hackinthosh-Scene sehr aktiv.
Gruss Arthur

Ich gebe zu, meine Xcode Erfahrungen beschränken sich auf eine vermutlich dilettantisch programmierte iOS-App vor mehreren Jahren und jüngst dem Versuch den Video-Player IINA aus dem Sourcecode zu compilieren. Dies habe ich dann nach 1-2h aufgegeben, weil ich die notwendigen Packages nicht in das Projekt bekommen habe.

Ich bin ja sicherlich nicht der schlaueste aber für mich suggeriert
/usr/local/ das hier nur Benutzer relevante Programme ihr unwesen treiben können die auch von Nutzer installiert wurden.
Ähnlich wie bei /opt
wo steht denn nun der Unterschied ob ich ein Dienstprogramm in den Programme Ordner kopiere und dort über den Installer mein Passwort eingebe zum installieren des Dienstes und ich gar nicht weis was im Hintergrund läuft, zum Homebrew welches mir genau anzeigen kann wie und wo installiert wird.

Beispiel Adobe CC da muss ich auch Dienste installieren und brauche das Admin Passwort.

Ok, wenn Homebrew (aus Sicherheitsgründen) auf so viel Ablehnung stößt und nach wie vor niemand die aktuelle rsync Version 3.2.7 als M1 binary compiliert hat, dann wäre doch eventuell MacPorts auch noch eine gute Alternative.

Voraussetzung ist, dass die Xcode command-line Developer Tools bereits installiert sind:


Den MacPorts Installer für Ventura, Monterey, Big Sur usw. bekommt man hier:



Nach der Installation einfach:


ausführen.

Das dauert dann zwar wesentlich länger als bei Homebrew (knapp 10 bis 15 Minuten), aber danach hat man ebenfalls eine aktuelle Version 3.2.7 von rsync einsatzbereit (liegt in /opt/local/bin/rsync).

Um rsync dann als 'Server' laufen zu lassen (damit HyperBackup das als "Ziel" akzeptiert), also


ausführen zu können, muss man die


umbenennen und natürlich für das gewünschte Verhalten anpassen.

PS: Falls sich jemand hier finden sollte, der die aktuelle rsync binary für M1 compiliert, dann ist vllt. noch ganz hilfreich zu wissen, was alles so an Abhängigkeiten mit installiert wurde bei der Installation von rsync per MacPorts:

Das da so viele Abhängigkeiten dabei sind fiel mir auch letztens auf. Ich habe bei mir Macports installiert. Ufert das bei z. B. Homebrew auch so aus? Mein Macports hat seit kurzem Schluckauf deswegen wäre ein Wechsel kein Problem.

Bozol: Nein, Homebrew hat bedeutend weniger Abhängigkeiten, da es viel häufiger (wenn möglich) auf bereits im System befindliche Unix binaries zurückgreift. Entsprechend dauerte die Installation von rsync unter Homebrew gestern auch nur 2-3 Minuten (gegenüber den 10-15 Minuten von MacPorts).

Ich persönlich sehe das eigentlich als Vorteil von Homebrew, andererseits pfuscht MacPorts natürlich viel weniger (bzw. genau genommen gar nicht) im System herum (verbiegt also z.B. keine Zugriffsberechtigungen im System).

Das muss man MacPorts schon zu gute halten im direkten Vergleich zu Homebrew denke ich.

PS: Und MacPorts efordert immer zwingend sudo, auch das umgeht Homebrew ja… dort reicht dann ein User mit Admin-Privilegien aus. Auch das spricht eher für MacPorts und gegen Homebrew…

Marcel_75@work

Danke für Deine Meinung. Dann werde ich bei MacPorts bleiben und mal neu aufsetzen, das bleibt nach einem macOS-Update nicht aus.

Bei mir ist bei der Suche nach vorkompilierten Binaries für M1-Macs noch die Frage aufgetaucht:

Warum unbedingt ARM64-Binaries?

Rosetta ist erfunden und die Performance von 'rsync' selbst dürfte ja völlig irrelevant sein. 'rsync' wartet doch die meiste Zeit eh' auf das Dateisystem oder das Netzwerk. DIE leisten die Arbeit, nicht 'rsync'.

@MetallSnake: Mit Verlaub, das ist Blödsinn. Wenn Du unter Windows (oder welchem OS auch immer) ein Verzeichnis(baum) "world writeable" machst und das dann in den Suchpfad für Programme packst, dann hast Du Dir auch dort ein Riesenprojektil in den Fuß geschossen. Das hat mit Unix höchstens insoweit etwas zu tun, als daß Unix stärker davon ausgeht, daß ein Anwender mit Administratorenrechten weiß, was er tut.

Nein, diese Suggestion ist falsch.

Es gibt, was die Sicherheit und Zugriffsrechte betrifft, keinerlei Unterschied zwischen /bin, /usr/bin und /usr/local/bin; in allen Ordnern hat ausschließlich root Schreibrechte.

Der Unterschied zwischen den Ordnern dient ausschließlich der Sortierung und Übersichtlichkeit: in /bin liegen die essentiellen Programme eines Unix-Systems wie cp (Kopieren), in /usr/bin die weit größere Anzahl von Programmen, die ein Unix-System auch noch installiert hat (und die User im Terminal aufrufen) und in /usr/local/bin lokale Programme, das heißt, Programme, die nicht mit der Unix-Distribution mitgeliefert werden, sondern von einem Nutzer des Systems individuell auf diesem spezifischen Rechner nachinstalliert werden.

Unix-Programme, die ein spezifischer Nutzer einfach so installieren und nur er sie danach nutzen könnte, müssten innerhalb des Heimordners dieses Nutzers liegen (/Benutzer/benutzername/).
Es geht nicht darum, was Homebrew installiert. Es geht darum, dass es dabei die Schreibrechte der Ordner so verändert, dass anschließend dauerhaft alle ungefragt in diese Ordner schreiben können ohne jede Kontrolle.
Eben. Und Homebrew ist so, als ob Du nach einmaliger Installation von Adobe CC nie wieder das Admin-Passwort bräuchtest, um weitere Dinge zu installieren. Ein absolutes No-Go.

Welcher Hirni hier auch immer einen Daumen runter vergeben hat: ist Euch nicht klar, dass das die exakte Anleitung zum Kompilieren von rsync 3.2.4 ist? Wer Copy & Paste kann, der kann mit dieser Anleitung auch rsync 3.2.4 kompilieren.

stargator, kannst Du das Ergebnis Deiner Mühen Tobias nicht einfach zukommen lassen (sofern ihm die 3.2.4 genügt)?

Die Sicherheitsmängel von Homebrew kann man sich doch einfach schützen, oder nicht? Wenn ich das Verzeichnis /opt/homebrew/ nach der Installation von Programmen mit anderen Zugriffrechten schütze, so dass ohne sudo keine Installation möglich ist, oder wenn ich meinem normalen Benutzer keine Admin-Rechte gebe, dann ist doch alles in Ordnung.
Wenn ich jedes Paket selber baue, wie führe ich dann Updates durch? Jedes mal erst prüfen, ob es Updates gibt und dann neu installieren? Mit Homebrew "brew update" und "brew upgrade" ist das jedenfalls ein Klacks.

Hallo zusammen,

vielen Dank erstmal! Ich kann -- mangels skills -- nichts konstruktives beitragen, finde den Austausch aber sehr interessant. Die Anleitungen für Homebrew und MacPorts sind auch für mich verständlich. Aktuell hoffe ich allerdings noch, ohne auszukommen.

Gegen eine 3.2.4 hätte ich nichts einzuwenden. Wenn stargator mir die liefern würde, würde ich dankend annehmen.

Gruß, Tobias

Sicherst du das ganze NAS per rsync auf den mac? Selbst wenn nicht, du kannst doch im NAS ein Share vom mac als Remote Folder einbinden und darauf sichern, damit bist du immer absolut unabhängig von jeglicher Prozessor Plattform. Dem Share ist es egal ob es nun per SMB, NFS oder was auch immer kommt und welches System OS zugrunde liegt. Zudem kannst du dafür einen eigenen User mit eingeschränkten Zugriffsrechten anlegen und bist damit auch auf der sicheren Seite.

Ich sichere ausgewählte Ordner. Deinen beschriebenen Weg muss ich mir mal angucken. Wenn das für mich funktionieren würde, müsste ich hier niemandem mehr mit meiner Unwissenheit auf den Zwirn gehen. Danke für den Tipp.

Also statisch kann ich das nicht kompilieren, deshalb muss man den Lib Ordner mitnehmen. Ich würde es eher selbst übersetzen. Hier ist der /usr/local folder mit rsync 3.2.7 für arm (bin und lib Ordner sind notwendig and der richtigen Stelle). und hier wie es generiert wurde: . Ich weiss nicht ob Tobias das passend zum laufen bekommt (es geht nur im richtigen Ordner und nur auf M1/M2).

Aber genau darauf weist tjost doch zurecht hin – bei Adobe CC ist es schon seit Monaten so, dass man das zwar einmalig (initial) mit Admin-Rechten installieren muss, die User danach aber selbst als Standard-User (also ohne Admin-Rechte) ihre Adobe CC Apps auf dem aktuellen Stand halten können.

Ebenso verhält sich auch der Microsoft-Updater, auch der nistet sich so ins System ein, dass sogar bei Standard-Usern ohne Admin-Rechte die Aktualisierungen "still und heimlich" im Hintergrund laufen können.

Ist natürlich super-praktisch dass das bei Bedarf so funktioniert, aus sicherheitstechnischer Sicht aber ähnlich 'problematisch' wie Homebrew.

Und ich glaube darauf wollte tjost hinaus?

Davon abgesehen können ausführbare Programme sich ja auch einfach irgendwo im $USERHOME "verstecken" und am Tag X "zuschlagen" – das gefährdet zwar zugegeben nicht gleich das gesamte System, sehr wohl aber sämtliche Benutzer-Daten.

Von daher halte ich die Diskussion über die Unsicherheit von Homebrew für ein wenig übertrieben. Zumal man sich genauso gut mit der Alternative MacPorts 'etwas böses' einfangen kann (theoretisch), denn wenn man eine 'verseuchte' binary erst einmal mit root-Rechten installiert hat, ist ja eh alles möglich.

Ich will da jetzt auch gar nicht lange drauf rumreiten. Eher wäre aus meiner Sicht der Hinweis angebracht, dass es durchaus eine gute Maßnahme ist, für die tagtägliche Arbeit einen Standard-Account ohne administrative Rechte zu nutzen.

Bei per "Mobile Device Management" verwalteten Geräten kann man dann 'on top' bei Bedarf auch noch einstellen, dass ausführbare Programme z.B. gar nicht aus dem Bereich $USERHOME erlaubt sind – so kann man z.B. perfekt vermeiden, dass irgend etwas aus dem Downloads-Ordner (oder vom USB-Stick und dann z.B. vom Schreibtisch aus) "gestartet" werden kann. Denn dann ist wirklich nur ausführbar, was aus /Applications und /Library kommt, wo ein Standard-User ohne Admin-Rechte ja keine Schreibrechte hat. Ausnahmen kann (und muss man) teilweise natürlich trotzdem noch definieren (z.B. für ~/Library/Application Support/xyz.you-name-it)…

Aber das nur so am Rande – ich will damit nur sagen, Homebrew ist nicht per se das Sicherheitsproblem, als das es hier dargestellt wird, da gibt es noch ganz andere Vektoren, die aus meiner Sicht schwerer wiegen.

Vielen Dank, stargator! Kurze Nachfrage dazu:

local/bin/rsync kopiere ich in usr/local/bin
Den kompletten Inhalt aus local/lib kopiere ich in usr/lib

Korrekt?

Nö, müsste auch /usr/local/lib sein. Wenn es lib innerhalb von /usr/local noch gar nicht gibt, kopierst Du einfach den ganzen Ordner lib hinein. Wie gesagt: Alles, was man in einem Unix-System zusätzlich installiert, gehört nach /usr/local/!

Aber wichtig: Nicht wie normal im Finder kopieren, sonst hast Du wieder das Problem mit veränderten Zugriffsrechten!

Entweder im Terminal mit

oder im Finder mit

• Quellobjekt auswählen und -C
• in Zielordner wechseln und dort -V (Objekt exakt einsetzen)

Nur dann behält der Finder die Original-Zugriffsrechte!

Nein, da verwechselst Du was. Adobe realisiert das technisch völlig anders. Durch das einmalige Eingeben des Admin-Passwortes bei der Installation erlaubst Du Adobe, im Hintergrund einen Update-Dämon mit root-Rechten laufen zu lassen, der dann zukünftig Updates installieren kann. An den Zugriffsrechten der Ordner-Hierarchie verändert Adobe nichts (jedenfalls bei allen Programmen, die ich habe).

Microsoft tut das oder tat das zumindest in der Tat, aber Du willst doch nicht Microsoft-Praktiken als Vorbild für Sicherheitsvorkehrungen anpreisen?
Nicht ganz. Wenn der Nutzer das todbringende Program eigenhändig startet, ist natürlich kein Kraut dagegen gewachsen. Wenn es aber Teil einer raffinierten Befehlskette ist, müsste der „versteckte“ Ordner in der Unix-Variable PATH gelistet sein, und da sind aus gutem Grund normalerweise eben keine Ordner innerhalb von Nutzerordnern aufgelistet.

Diese ganzen Einwände, die keine sind, weil Unix dann eben doch etwas ausgeklügelter ist, zeigen mir, dass in der Tat viele gar nicht wirklich erfassen, eine wie große Sicherheitslücke sie sich mit Homebrew ins Haus holen.
Wie auch immer. Wer von Unix-Sicherheit entweder so wenig versteht oder aber sie wider besseres Wissen missachtet, wie das bei dem Homebrew-Team der Fall zu sein scheint, von dem will ich sowieso nicht geschenkt irgendwelche kompilierten Programme bekommen. (Ich erinnere mich vage an völlig unnötige Sourcecode-Veränderungen in Homebrew, die mir die Haare zu Berge stehen ließen … – das ist aber schon lange her.)

Sorry Weia, aber so einfach lasse ich dich jetzt nicht davon kommen…

Ich habe ja schon ab und an am Rande mitbekommen (in anderen sehr ausufernden Threads), dass Du perfekt darin bist, ausschließlich das zu zitieren, was Dir für Deine Argumentationskette gerade gut in den Kram passt (und alle anderen Argumente dann geflissentlich unter den Tisch fallen lässt).

Ich komme noch einmal auf das Beispiel mit den Apps in $USERHOME zurück. Sagen wir mal, eine App gibt sich als Tool aus für die Umwandlung von PDF in .docx oder .xlsx. Der User startet also den Installer und wählt meinetwegen sogar aus, dass die App nicht in /Applications landen soll sondern nur in ~/Applications.

Er benutzt die App auch ab und an und ist damit happy – sieht also alles gut aus und macht was es soll das Tool.

Du weißt mit Sicherheit selbst, was man in so einer PKG alles machen kann, u.a. können weitere ausführbare Binaries per post install script in ~/Library/… landen und diese lauern dann dort eben als "timebomb" auf den Tag X und werden vom 'Hauptprogramm' aufgerufen (um z.B. alle User-Daten zu verschlüsseln oder auch einfach böswillig zu löschen).

Wie viele User schauen bitte vorher per "SuspiciousPackage" oder "Pacifist" in so ein Installations-Paket? Wahrscheinlich einer von 100, wenn nicht sogar einer von 1000.

Was bitte ist aus Deiner Sicht jetzt genau die "größere Gefahr" beim Einsatz von Homebrew?

Auch bei Homebrew muss der User ja erst einmal irgend etwas "anschubsen" – ob ich nun also Homebrew nutze um mir eine extra binary zu installieren oder als "Nutzer das todbringende Programm eigenhändig starte" (um mal bei Deiner Formulierung zu bleiben) läuft am Ende doch auf das selbe hinaus, oder?

'Von alleine' landet mittels Homebrew ja nichts auf meinem Rechner – also ist es auch fast "egal", ob da jetzt Rechte im System 'umgebogen wurden' oder Path-Variablen anders gesetzt wurden (bitte nicht missverstehen, ich persönlich sehe das natürlich auch kritisch) – aber am Ende entscheide ja immer noch ich als User, was per Homebrew (oder auch MacPorts) auf meiner Kiste landet und was nicht.

Und als Standard-User ohne Admin-Rechte ist die (theoretische) Gefahr sogar noch geringer, denn bei MacPorts kommst Du ohne sudo gar nicht ans Ziel und bei Homebrew benötigst Du zumindest Admin-Rechte.