Die Zukunft von macOS mit ARM-Prozessoren?!

@einseinsnull
netter Versuch, immer weiter vom Thema weg zu kommen. Und toll von dir, mir selbst antrainiertes, kritiklosen Denken und nicht selbstbestimmtes Handeln zu unterstellen. Mehr kriegst du nicht hin? Komm, du schaffst es sicher noch ein wenig anmaßender.
[...]
Bleib doch mal beim Thema. Ist schwer für dich, oder?

mein thema war dieser beitrag vor dir:

Bei allem, was auf der WWDC gesagt und gezeigt wurde, bleibt es auf dem Mac so wie bisher. Du wirst Software installieren können, woher du sie auch haben willst.
Klar werden jetzt manche behaupten, dass Apple lügt. Aber die haben dann IMO ein anderes Zwangs-Problem.

dass du findest, dass alle die nicht deiner meinung sind und sich erlauben hin und wieder nicht alles glauben zu wollen, was apple erzählt, eine psychische störung haben ist dein problem.

deine behauptung, dass man auch weiterhin auf einem mac alles installieren kann, was man will, halte ich jedenfalls für falsch, was war der kern meiner aussage.

lediglich einige wenige spezialisten wie du und ich werden in der lage sein, die ganze gatekeeper und xattr sch... zu umgehen um sich jegliche software auf seinem rechner zu installieren.

und selbst wenn man weiß, wie es geht, ist es recht umständlich im alltag.

noch komplizierter wird es, wenn du der autor einer ausführbaren datei bist und anderen deine software ohne signature und notarisation überlassen willst.

lieferst du das tool nicht mit, kann der andere dein programm nicht benutzen. lieferst du es mit, besteht die gefahr, dass er es auch für programme auf unseriösen quellen benutzt.

apple treibt mit diesen sicherheits- und kontrollgeschichten seit jahren zunehmend selbst mittelgroße entwicklerfirmen in den wahnsinn, ganz zu schweigen von lieschen müller, die mal eben schnell ein paar selbstgemachte tools freunden per email schicken will.

wenn man das alle so ohne weiteres auch ganz leicht umgehen könnte, dann könnte man es ja auch gleich weglassen.

mit ARM hat das übrigens auch nichts zu tun, eher mit macOS.
 
dass du findest, dass alle die nicht deiner meinung sind und sich erlauben hin und wieder nicht alles glauben zu wollen, was apple erzählt, eine psychische störung haben ist dein problem.

es geht nicht um meine Meinung, es geht um Aussagen von Apple auf der WWDC 2020. Meine Meinung dagegen ist, dass jemand, der Apple auf einer Entwicklerkonfernz unterstellt, sie lügen alle Entwickler an, selbst ein Problem hat, das er angehen sollte. Ganz nebenbei hast du mich dann auch noch persönlich angegriffen und mir nicht selbstbestimmtes Handeln unterstellt und mich des antrainierten, kritiklosen Denkens beschuldigt. Tolle Art von dir.

deine behauptung, dass man auch weiterhin auf einem mac alles installieren kann, was man will, halte ich jedenfalls für falsch, was war der kern meiner aussage.

wie gesagt, ich behaupte es nicht nur, ich belege es durch die Aussagen von Apple auf der WWDC und durch Doku von Apple. Wenn du natürlich Apple unterstellst, dass sie damit lügen, dann ist für dich auch meine darauf basierende Behauptung falsch.

lediglich einige wenige spezialisten wie du und ich werden in der lage sein, die ganze gatekeeper und xattr sch... zu umgehen

Das hier gibt mir zu Denken. Ist es vielleicht möglich, dass du nicht über alle Möglichkeiten informiert bist?

und selbst wenn man weiß, wie es geht, ist es recht umständlich im alltag.

Da ist nichts kompliziert. Eine App die nicht Code-signiert ist, kannst du so wie bisher mit Rechtsklick und im Dailog auf "Öffnen" weiterhin starten. Ebenso bei nicht notarisierten Apps.
Software die du selbst kompilierst und auf deinem System laufen lässt, musst du auch weder signieren noch notarisieren.

Dein Problem nun ist, dass du die folgenden Aussagen von Apple dazu nicht glauben wirst, da Apple ja deiner Meinung nach lügt. Ich werde den Link trotzdem posten, da es sicher andere mitlesende User gibt, denen die Infos was bringen.

Im folgenden Link beschreibt Apple u.a. wie man eine App, die nicht signiert und nicht notarisiert ist, dennoch öffnen kann. Das geht ganz ohne Gatekeeper auszuschalten oder mit xattr im Terminal rumzuspielen. Lies den Abschnitt, "How to open an app that hasn’t been notarized or is from an unidentified developer". Besonders die *-Fußnote ganz unten ist interessant, oder?

https://support.apple.com/en-us/HT202491

Und hier die Infos von Apple zur Notarisierung im Allgemeinen, wenn du mehr darüber wissen möchtest

https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

noch komplizierter wird es, wenn du der autor einer ausführbaren datei bist und anderen deine software ohne signature und notarisation überlassen willst.

lieferst du das tool nicht mit, kann der andere dein programm nicht benutzen. lieferst du es mit, besteht die gefahr, dass er es auch für programme auf unseriösen quellen benutzt.
Welches Tool musst du denn mitliefern? Mir ist da keines bekannst.

Ach ja, zuletzt nochmal die Frage: Was hat deine Argumentation von Überwachung und Scientology mit meinem Postng über die Möglichkeit auch Apps außerhalb des Stores installieren zu können, zu tun? Da du das nun übergehst, gebe ich mir die Antwort mal selber: Nichts.
 
  • Gefällt mir
Reaktionen: chris25, Madcat, electricdawn und eine weitere Person
ich stelle mir einen unibody so vor wie apple ihn mir erklärt hat.
Ich weiß nicht wie du die ein Unibody vorstellst aber wenn das von der Erklärung, was Apple unter einem Unibody versteht, abweicht, solltest du in Erwägung ziehen, dass du dir vielleicht den Unibody falsch vorstellst und nicht Apple unterstellen, dass es die User anlügt.
solltest du vielleicht einfach mal schauen, was apple dazu sagt und um was überhaupt geht:

https://de.wikipedia.org/wiki/Unibody-Design
Ist ja lustig, ich soll schauen was Apple dazu sagt und du verlinkst worauf? Warum gibst du denn nicht direkt die Quelle bei Apple an? War das jetzt zu schwer oder wie? Ganz ehrlich, dieser Wikipedia-Artikel prangert das Displaygehäuse an...weil die Glasscheibe eingeklebt ist und das Gehäuse, nicht näher angegeben, verschraubt ist. Da fragt man sich: Was hat sich der Author dabei gedacht? Dass das Display nur mit Luft und Liebe im Displaygehäuse hält? Wie soll denn die Glasscheibe vor dem Display halten? Würde mich echt nicht wundern, wenn der Artikel von dir stammt. Dieser Artikel zeigt nur, dass der Author keine Ahnung von Unibody hat.

Aber erhelle uns doch mal, beschreibe uns doch mal detailiert, wie ein Unibody aussehen müsste damit es sich so nennen darf. Wie muss man die Glasscheibe im Displaygehäuse befestigen, wie das Display ansich? Darf man denn die Schaniere wenigsten anschrauben oder müssen die auch aus dem Vollen gefräst sein?
 
  • Gefällt mir
Reaktionen: lisanet, electricdawn und BrooksDunn
Dieses Forum spielt echt mit meinen Emotionen ... da denkst du der Tag kann nicht noch schlimmer werden, kommste her - musste sowas lesen :D
I bims, 1 Juni-Body :crack:
 
https://www.heise.de/news/Apple-ARM-Macs-fuehren-nur-noch-signierten-Code-aus-4875048.html

ARM-Macs führen nur noch signierten Code aus um vor Binary-Modifikationen zu schützen (siehe die erst kürzlich von Microsoft gestopfte GlueBall-Lücke). Dieser benötigt allerdings weiterhin kein offizielles Developer Zertifikat sondern kann stattdessen auch ad-hoc vom Compiler bzw. Linker mit einem selbst erzeugten Zertifikat zum Zeitpunkt der Erstellung der Binary signiert werden. Dadurch ist sichergestellt, dass sich weiterhin beliebige Software ausführen lässt. Der entsprechende Passus aus Apples Release Notes:

Updates in macOS Big Sur 11 Universal Apps Beta 4
Code Signing
New Features in macOS Big Sur 11 Universal Apps Beta 4
  • Starting with Xcode 12 beta 4, the toolchain will now automatically sign your executables whenever you build from Xcode, or use command-line utilities such as clang(1) or ld(1). This new mechanism generates signatures directly at link time, and doesn’t cover any resource other than the executable. As a result, it’s expected to be faster than a traditional codesign(1) invocation. If you use a custom workflow involving tools that modify a binary after linking (e.g. strip or install_name_tool) you might need to manually call codesign(1) as an additional build phase to properly ad-hoc sign your binary.
    New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature issued locally is sufficient, which includes signatures which are now generated automatically by the linker. This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs, and is designed to simplify the execution policies on Apple silicon Mac computers and enable the system to better detect code modifications.
    This new policy doesn’t apply to translated x86 binaries running under Rosetta, nor does it apply to macOS 11 running on Intel platforms. (51911409)
Quelle: https://developer.apple.com/documen...-big-sur-11-universal-apps-beta-release-notes

Bin mal gespannt wie das in der Praxis aussehen wird. An sich dürfte sich dadurch für den Endanwender nichts ändern wenn ich das richtig verstehe.
 
  • Gefällt mir
Reaktionen: lefpik, ma2412, lisanet und eine weitere Person
This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs, and is designed to simplify the execution policies on Apple silicon Mac computers and enable the system to better detect code modifications.

Und auch hier wiederholt Apple ihre Zusicherung, wie auch auf jeder WWDC der letzten Jahre.
 
ARM-Macs führen nur noch signierten Code aus um vor Binary-Modifikationen zu schützen (siehe die erst kürzlich von Microsoft gestopfte GlueBall-Lücke). Dieser benötigt allerdings weiterhin kein offizielles Developer Zertifikat sondern kann stattdessen auch ad-hoc vom Compiler bzw. Linker mit einem selbst erzeugten Zertifikat zum Zeitpunkt der Erstellung der Binary signiert werden. Dadurch ist sichergestellt, dass sich weiterhin beliebige Software ausführen lässt. Der entsprechende Passus aus Apples Release Notes:
Wie so etwas die Sicherheit steigern soll, wenn der Compiler/Linker sich selbst das Zertifikat erstellen kann, erschließt sich mir nicht wirklich. Was sollte Entwicker von Schadsoftware denn daran hindern, sich ihre Zertifikate dann selbst auszustellen? Ach wahrscheinlich ists grad zu spät und ich bekomm eh nix mehr auf die Kette...🤔
 
Da liegst Du nicht ganz falsch. Was hindert einen Malware-Programmierer daran, einen ganz normalen Mac zu nutzen und mit Xcode seinen Code zu kompilieren?

Da stimmt irgendwas nicht...
 
Da liegst Du nicht ganz falsch. Was hindert einen Malware-Programmierer daran, einen ganz normalen Mac zu nutzen und mit Xcode seinen Code zu kompilieren?

Da stimmt irgendwas nicht...
Bislang sind binaries nicht signiert und künftig können sie von Nicht-Apple-registierten Developeren eben selbst signiert werden. Das ändert nichts an der Sicherheitsstufe mit der Ausnahme, dass bei binaries / Apps mit Signatur eine nachträgliche Änderung des Codes erkannt werden kann.

Die "Sicherheit" ist wie bisher die Signierung mit einem registrierten Developer-Zertifikat und der Notarisierungsprozess.
 
Also keine Sicherheit. Wenn ich das Ok mit meinem Administratorpasswort gebe, dann läuft der Code.

Verstehe mich bitte nicht falsch. Ich bin für Brain 2.0. Die Leute müssen darüber nachdenken, was sie da laufen lassen. Aber die Selbstzertifizierung ist kein Schutz gegen Malware. Was soll das Ganze also?
 
Aber die Selbstzertifizierung ist kein Schutz gegen Malware. Was soll das Ganze also?
stimmt, es ist kein Schutz gegen Malware, so wie bisher auch bei unsignierten binaries. Es ist ein Schutz gegen nachträgliche Manipulation und vereinfacht den OS-seitigen Verifizierungsprozess.
 
Ok... Nehmen wir das mal so. Es ist ein kleiner Schutz. Und ja, der Code ist gegen nachträgliche Manipulation geschützt, was man nicht unterschätzen soll. Wobei ich nicht weiss, ob es schon Malware gibt, die wirklich Programme auf dem Festspeicher manipuliert. Und nur da wäre dieser Schutz sinnvoll. Na ja... :hum:
 
stimmt, es ist kein Schutz gegen Malware, so wie bisher auch bei unsignierten binaries. Es ist ein Schutz gegen nachträgliche Manipulation und vereinfacht den OS-seitigen Verifizierungsprozess.
Was hinter mich als Virus da dran, nachdem ich ein Binary verändert habe, eine neue Signatur dafür zu erstellen?
 
Ok... Nehmen wir das mal so. Es ist ein kleiner Schutz. Und ja, der Code ist gegen nachträgliche Manipulation geschützt, was man nicht unterschätzen soll. Wobei ich nicht weiss, ob es schon Malware gibt, die wirklich Programme auf dem Festspeicher manipuliert. Und nur da wäre dieser Schutz sinnvoll. Na ja... :hum:
Denke doch mal an plugins für Apps, oder den Austausch einer dylib um damit z.B. Kopierschutzmechanismen zu umgehen, oder ausgetauschte Komponenten nach einem Einbruch auf dem Downloadserver oder nachgeladene Komponenten aus dem Netz
 
Zurück
Oben Unten