Connect with us

Entwicklung & Code

Linux App Summit 2026: Treffen der Linux-Desktop-Avantgarde


Weiterlesen nach der Anzeige

Klein, aber fein war das Treffen der Linux-Desktop-Community. Auf dem Linux App Summit (LAS 2026) Mitte Mai in Berlin trafen sich rund 110 Personen, darunter war projektübergreifend die Avantgarde der Entwickler für moderne Linux-Systeme vor Ort. Dabei ging es weniger um das Aussehen der Desktopoberfläche, als um grundlegende Konzepte, um die Installation einfacher, das System sicherer und robuster sowie die Benutzung komfortabler zu machen. Statt um Desktop-Themes, Distributionen und Pakete drehten sich die Gespräche um Images, Apps und wie das teils veraltete Linux-Ökosystem wieder zu modernen Betriebssystemen wie Android/ChromeOS, macOS und ja, auch Windows, aufschließen kann.

Die etwas mehr als ein Dutzend Vorträge waren sinnbildlich eingerahmt zwischen der Eröffnungs-Keynote von systemd-Erfinder Lennart Poettering und dem Schlussvortrag von Jorge Castro, Initiator des Projektes Universal Blue, aus dem die modernen Linux-Systeme Bluefin und Bazzite hervorgegangen sind. Beide, Castro und Poettering, fordern ein grundlegendes Umdenken, wie Linux-Betriebssysteme bereitgestellt werden, verfolgen aber unterschiedliche Ansätze.

Lennart Poettering plädierte in seiner Keynote für eine strikte Trennung von Betriebssystem und lokalen Daten (Inhalt der Benutzerverzeichnisse, lokale Konfigurationen et cetera), wo ersteres über ein unveränderliches, für alle gleiches Image verteilt wird. Das erlaubt, die Authentizität des Betriebssystems kryptografisch sicherzustellen, indem vereinfacht gesagt Prüfsummen der Images, aber auch anderer Komponenten wie Kernel und Bootloader, über den TPM-Chip abgesichert sind. Weitere Komponenten kann man als Erweiterungen einklinken, die ebenfalls als verifizierbare Images vorliegen. Manipuliert jemand einen Teil des Systems, ändern sich Hashwerte und führen dazu, dass das TPM-Modul den weiteren Bootvorgang und die Entschlüsselung der Partition mit den lokalen Daten verweigert. Gleichzeitig erlaubt das Design, mithilfe eines korrekten Images den Werkzustand wiederherzustellen.



Systemd-Erfinder Lennart Poettering hielt auf dem LAS 2026 die Eröffnungs-Keynote.

(Bild: Linux App Summit)

Poetterings Ziel ist es, die Zustandsräume (State Spaces) zu verkleinern, also die Unterschiede zwischen verschiedenen Installationen, um die Prüfung und Absicherung der Systeme zu erleichtern. Ihm schwebt vor, das aus dem Speichermanagement bekannte Sicherheitskonzept „Schreiben oder Ausführen“ (W^X) auch auf das Dateisystem auszuweiten. Code solle nur dann ausgeführt werden, wenn dieser von einem überprüften, unveränderlichen Image komme. Er betont aber: „Sicherheit ist nie binär, sondern eine graduelle Angelegenheit.“ So könne etwa innerhalb von Containern was anderes gelten, wenn alles im Userspace läuft und voneinander abgeschottet ist.

Um das zu realisieren, kommen viele unterschiedliche Komponenten von systemd zum Einsatz, etwa systemd-sysupdate, systemd-repart, oder Standards aus dessen Umfeld, wie Discoverable Disk Images. Poettering hat gemeinsam mit anderen Entwicklern die Firma Amutable gegründet, die ein verifizierbares Linux-System anbieten wollen, was aber eher auf Server und Rechenzentren abzielt.

Weiterlesen nach der Anzeige

Für den Desktop setzt neben ParticleOS aus dem systemd-Projekt insbesondere Gnome OS Poetterings Ideen um. An dessen Umbau war maßgeblich der Gnome-Entwickler Adrian Vovk beteiligt, der auch auf der LAS 2026 anwesend war.

Auch Kubernetes-Spezialist Jorge Castro fordert ein radikales Umdenken und will ein robustes Linux-System, geht aber mit seinem Projekt Universal Blue einen anderen Weg, indem er Erfolgskonzepte von Containern, etwa Docker, auf den Linux-Desktop übertragen will. „Es gibt 20 Millionen Entwickler in der Cloud-Native-Community“, betont Castro im Gespräch mit c’t. „Ich sehe es als meinen Job an, die wieder für Betriebssystem zu begeistern, damit Gnome und KDE Bestand haben.“ Die Cloud-Entwickler will er mit dem Projekt Universal Blue erreichen, das auf dem von Red Hat entwickelten, aber stiefmütterlich behandelten, Fedora Silverblue basiert. Das System startet aus einem bootbaren Container; Updates holt das Tool bootc ähnlich, wie man es von Docker gewohnt ist. Die Images, also OCI-Container, bauen Castro und seine Mitstreiter automatisiert auf GitHub. Mit Universal Blue hat Castro eine ganze Reihe moderner Linux-Systeme losgetreten.


Jorge Castro Portraitfoto beim Interview

Jorge Castro Portraitfoto beim Interview

Bluefin-Initiator Jorge Castro erläuterte seine Vision eines Linux-Desktops im Gespräch mit c’t.

(Bild: Keywan Tonekaboni / heise medien)

Bluefin nutzt ein aufgehübschtes Gnome, setzt komplett auf Apps aus Flathub sowie Kommandozeilentools aus Homebrew und soll eine Nutzererfahrung wie ChromeOS bieten. „Chromebooks sind super, ich will diese Power mit einem normalen Linux“, sagte Castro in Berlin. Von Bluefin inspiriert entstand Bazzite mit KDE Plasma, was SteamOS des Gaming-Handhelds Steam Deck nachempfunden ist, Steams Gaming Mode unterstützt und so abseits typischer Linux-Zielgruppen auf Resonanz stieß. Auf mobilen Konsolen, wie dem Asus ROG Ally, laufen Spiele mit Bazzite teils schneller, als mit dem vorinstallierten Windows. „Gamer Nerds retten möglicherweise den Linux Desktop“, meint Castro. Im projekteigenen Discord würden 33.000 „Kids“, so Castro, abhängen: „Neue User ganz ohne schlechte Gewohnheiten.“

Den anwesenden Gnome- und KDE-Entwicklern empfahl er, das Schicksal in die eigene Hand zu nehmen und ein eigenes Desktop-Produkt auszuliefern, das Out-of-the-Box funktioniert. Bei klassischen Distributionen gäbe es zu viele Altlasten. „Die Leute gehen mit X11 nach Hause, was eure Arbeit erschwert“, klagte Castro. „It hurts me!“

Castro kritisierte aber auch, dass trotz mehrfacher Ankündigung im de-facto Linux-App-Store Flathub es nicht möglich ist, für Apps zu bezahlen oder auch nur zu spenden.

Was mit modernen Linux-Komponenten möglich ist und wo die Grenzen liegen, zeigte Spectrums Projektleiterin Alyssa Ross. Spectrum priorisiert Sicherheit und ähnelt Qubes OS, welches Umgebungen wie „Arbeit“ oder „Privat“ mittels virtueller Maschine (VM) abschottet. Spectrum setzt das radikaler um, weil jede App in einer eigenen VM startet. Apps interagieren mit dem Betriebssystem zusätzlich zu den VM-Schnittstellen wie virtio-gpu und virtio-fs auch über Desktop Portals, wie sie bei Flatpak und Snap eingesetzt werden. Dank Wayland verhalten sich die Anwendungen wie normale Fenster, ein virtuelles Display gibt es nicht, und trotz der Abschottung klappt auch die Zwischenablage.


Alyssa Ross hält ihren Vortrag zu Spectrum

Alyssa Ross hält ihren Vortrag zu Spectrum

Wie Spectrum konsequent einzelne Apps untereinander isoliert, zeigte Alyssa Ross auf dem LAS 2026 in Berlin.

(Bild: Keywan Tonekaboni / heise medien)

Spectrum blockiert per Vorgabe alle Berechtigungen, was manchmal nicht so einfach ist. Ross beklagte etwa, dass es bei den Desktop Portals keine Audio-Schnittstelle gibt, das den Zugriff auf das Mikrofon regelt. Sobald eine App Zugang zu der Audioschnittstelle von Pipewire hat, kann sie alle verfügbaren Audio-Geräte nutzen, inklusive aller Mikros.

Als Herausforderung bei der Entwicklung von Spectrum bezeichnete die Projektleiterin den Spagat zwischen der Desktop-Arbeit und der Hypervisor-Arbeit. Das Projekt will mit dem Linux-Desktop-Ökosystem zusammenarbeiten und verfolgt eine Upstream-First-Philosophie, weshalb Spectrum keine eigenen Apps entwickelt.

Über den Status von Flatpak und dessen Zukunftspläne berichteten Adrian Vovk und Sebastian Wick, welcher seit vergangenem Jahr neuer Maintainer ist. Die Stagnation bei der Entwicklung von Flatpak sei überwunden, so Wick. Ein Security-Audit hatte einige Sicherheitslücken offenbart, darunter ein Ausbruch aus der Sandbox mittels „path traversal“ (Manipulation eines geöffneten Dateipfades, um Zugriff auf andere Dateien zu erlangen), der schwer zu korrigieren war, weil er sich durch den gesamten Flatpak-Stack zog. Ein erster Fix legte Steam und alle Chrome-basierten Browser lahm, und eine kompatible Lösung zu finden, kostete viel Arbeit.

Neu sind bedingte Berechtigungen. Apps können prüfen, ob es Portals wie das neue USB-Portal gibt, sonst auf veraltete Berechtigungen wie „Alle Geräte“ zurückfallen. Das soll der Verbreitung von Portals helfen, ohne die Apps auf älteren Systemen unbrauchbar zu machen.

Derzeit experimentiert das Flatpak-Team damit, Apps, die noch das veraltete X11-Anzeigesystem verwenden, keinen Zugriff mehr auf das systemweite Xwayland zu geben, sondern für jede solche Anwendung mit Xwayland-satellite eine eigene X11-Umgebung zu starten. Das würde einerseits auch X11-Apps untereinander abschotten, wie es bereits bei Wayland der Fall ist, und andererseits perspektivisch erlauben, aus Wayland-Compositor wie Gnome-Shell den X-Window-Manager-Code herauszuwerfen.

Allgemein machen sich die rund elf Jahre, die Flatpak auf dem Buckel hat, schon bemerkbar. Es fehle teilweise an Abstraktionen, und die notwendige Rückwärtskompatibilität verhindert größere Änderungen. Daher planen Wick und Vovk im Rahmen von Flatpak Next alles neu zu programmieren. Dass dies in Rust geschehen soll, sorgte im Saal für Begeisterung. Dabei soll von Anfang an eine bessere Abstraktion stattfinden, die etwa den Austausch des Speichermechanismus ermöglicht. Flatpaks wären dann denkbar als OSTree, OCI-Container oder DDI.

Statische Berechtigungen, die Löcher in die Sandbox bohren, will das Team künftig nicht mehr ohne Weiteres erlauben. Für Apps soll es künftig zwei Modi geben. Im „confined mode“ sind statische Berechtigungen nicht erlaubt, weshalb sie komplett in der Sandbox laufen und Portals verwenden müssen. Der laxere „unconfined mode“ läuft auf dem Host und nutzt nur die Flatpak-Laufzeitumgebung. Man wolle, so Wick, Vertrieb von Apps und den Einsatz der Sandbox voneinander trennen. Der „unconfined mode“ soll nur mit Flatpak-Quellen („remotes“) möglich sein, denen der User vertraut. Flatpak Next soll für die Sandbox kein bubblewrap verwenden, da selbst ältere Distributionen die Trennung mittels unprivilegierter User-Namespaces unterstützen.

Neue Portals sind ebenfalls geplant, etwa für Rechtschreibprüfung, Passwort-Manager oder für Credentials wie FIDO2-Sicherheitsschlüssel und Passkeys, aber auch um den von Ross vermissten Mikrofon-Zugriff zu regeln. Auch die Portals sollen eine neue Architektur bekommen und Varlink statt D-Bus verwenden. Authentifizierung der Apps und Rechtemanagement soll die von Vovk und Wick neu angedachte systemd-Komponente systemd-appd übernehmen.

Flatpak Next und das bisherige Flatpak sollen parallel installierbar sein und sich nicht ins Gehege kommen; gleiches gilt für die Portals. Gegenüber c’t sagte Wick, es sei einfacher anhand der Erfahrungen Flatpak sauber neu zu entwickeln, als um die Altlasten herumzumanövrieren.

Interessanterweise wies Collabora-Entwickler Thorsten Behrens in seinem Vortrag darauf hin, dass ein Rewrite immer den Nutzen für die User im Fokus haben sollte und kein Selbstzweck sein sollte. So manches trendige Framework sei nach kurzer Zeit schon wieder eingestampft worden.



Tony Wasserka arbeitet an FEX mit und erläuterte, wie der Emulator unveränderten x86-Code auf ARM64-Systemen ausführt und welche Klimmzüge dafür nötig sind.

(Bild: Linux App Summit)

Wie man eine Brücke zwischen zwei Welten schlägt, zeigte Tony Wasserka, der am Emulator FEX mitarbeitet, welcher unveränderten x86-Code auf ARM-Systemen ausführt. Valve plant FEX auf dem angekündigten VR-Headset Steam Frame einzusetzen. Die Schwierigkeit bestehe darin, den x86-Binärcode zur Laufzeit für ARM64 zu rekompilieren und ihn gleichzeitig zu optimieren, um den Code auch schnell genug auszuführen. Wasserka gab Einblicke, wie sie das erreichen. So rekompiliert FEX-Emu den x86-Maschinencode zunächst in eine Zwischensprache um, die dann optimiert wird und woraus dann ARM64-Maschinencode kompiliert wird. Bereits rekompilierte Codestücke speichert FEX-Emu in einem Cache zwischen.

Probleme entstehen etwa dadurch, dass sich das Speichermodell zwischen x86 und ARM64 unterscheidet. Bei Multithreading tauchen Variablen teilweise in einer anderen Reihenfolge auf, als es bei x86 der Fall ist. Das konsequent abzufangen erzeugt einen Overhead, der die Performance massiv drückt. Wasserka und seine Mitstreiter entwickelten daher Heuristiken, um den Overhead nur dort zu erzeugen, wo er zwingend notwendig sei. So habe es bei Unity-Spielen schon gereicht, nach einem bestimmten Memory load offset Ausschau zu halten, sonst sei die Reihenfolge vernachlässigbar. „Es ist erschreckend, wie gut der Trick funktioniert“, resümierte Wasserka.

Ein weiterer Schritt bestand darin, Wrapper für Syscalls zu schreiben. Das sei zwar oft einfach, aber da es Hunderte von ihnen gibt, in der Summe aufwendig. Diese Arbeit sei aber jetzt fast komplett abgeschlossen. Bei Windows-Programmen profitiert das FEX-Emu-Team von den ARM64EC-Windows-Bibliotheken, die Microsoft öffentlich bereitstellt. Der Code der Windows-Programme wird für die ARM64EC-Schnittstelle rekompiliert. Dadurch fallen viele Zwischenschichten weg, wie x86-Wine, x86-Windows- und Linux-Bibliotheken sowie Kernel-Kompatibilitätsschichten. Stattdessen reichen der Rekompilierer, ein WINE für ARM sowie die ARM64EC-Bibliotheken, die direkt mit dem ARM-Kernel interagieren können. Wasserka demonstrierte dem LAS-2026-Publikum FEX live, indem er ein x86-Steam auf seinem ARM64-Notebook öffnete und das Spiel Tunic startete, welches weitgehend flüssig lief.

c’t Open Source Spotlight abonnieren

Innovative Software, spannende Projekte: Erweitern Sie Ihre Möglichkeiten und werden Sie Teil der Open Source Community.

E-Mail-Adresse

Ausführliche Informationen zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten erhalten Sie in unserer Datenschutzerklärung.

Linux auf dem Desktop hat es derzeit nicht einfach, da aktuell kaum Geld in den Linux-Desktop fließt. Das zeigt auch ein Blick auf die Sponsoren des LAS 2026, die nicht mehr so zahlreich sind wie noch vor einigen Jahren. Umso engagierter ist die Community, die innovative Ideen ersinnt und umsetzt, wie Bluefin, Bazzite oder Gnome OS zeigen. Die Aufzeichnungen der Vorträge des Linux App Summit sind auf YouTube verfügbar.

Lesen Sie auch


(ktn)



Source link

Entwicklung & Code

US-Regierung erzwingt Abschaltung von Anthropics KI Fable 5 und Mythos 5


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Anthropic muss seine KI-Modelle Fable 5 und Mythos 5 für alle Kunden weltweit abschalten. Auslöser ist nach Darstellung des Unternehmens eine Exportkontrolldirektive der US-Regierung, die am 12. Juni 2026 eingegangen sei und ausländischen Staatsangehörigen den Zugriff auf beide Modelle untersagt – auch ausländischen Anthropic-Mitarbeitern innerhalb der USA. Alle übrigen Claude-Modelle seien von der Anordnung nicht betroffen. Die Maßnahme reiht sich in eine bereits zuvor eskalierte Auseinandersetzung zwischen Anthropic und Teilen der US-Sicherheitsbürokratie ein.

Weiterlesen nach der Anzeige

Wie Anthropic in einer Stellungnahme erklärt, habe die Behörde keine konkreten technischen Details zu den angeführten nationalen Sicherheitsbedenken genannt. Nach dem Verständnis des Unternehmens geht die Regierung davon aus, dass eine Methode existiere, um Fable 5 zu „jailbreaken“, also dessen Schutzmechanismen zu umgehen. Anthropic bezeichnet die Maßnahme als „Missverständnis“ und arbeitet an der Wiederherstellung des Zugangs.


Screenshot der Startseite von Claude.

Screenshot der Startseite von Claude.

Beim Start von Claude verweist Anthropic auf die Erklärung, warum Fable 5 derzeit für alle Kunden deaktiviert ist.

Die beanstandete Technik beschreibt Anthropic als verbal überlieferten, potenziell nicht-universellen Jailbreak. Im Kern bestehe er darin, das Modell anzuweisen, eine bestimmte Codebasis zu lesen und Softwarefehler zu beheben. Eine Demonstration dieser Technik habe man geprüft und dabei lediglich eine kleine Zahl bereits bekannter, geringfügiger Schwachstellen gefunden, die auch andere öffentlich verfügbare Modelle aufspüren könnten – das Unternehmen nennt in diesem Zusammenhang ausdrücklich OpenAIs GPT-5.5.

Aus Sicht von Anthropic handelt es sich dabei um eine alltägliche Fähigkeit, wie sie Sicherheitsfachleute täglich bei legitimen Code-Reviews und beim Bugfixing nutzen. Der entscheidende Unterschied liege nicht in der Funktion selbst, sondern im Kontext: Derselbe Vorgang könne in einem Sicherheitsreview erwünscht sein, in einem anderen Szenario aber als potenzieller Missbrauch gewertet werden. Einen universellen Jailbreak, der die Schutzmechanismen von Fable 5 grundsätzlich aushebelt, habe man bislang nicht gefunden.

Anthropic verweist auf eine sogenannte „Defense-in-Depth-Strategie“: Jailbreaks sollen entweder eng begrenzt oder sehr aufwendig sein und werden durch Monitoring ergänzt, das erfolgreiche Angriffe schnell erkennen soll. Für Fable 5 gelte zudem eine 30-tägige Datenspeicherungspflicht, um Umgehungsversuche analysieren und eindämmen zu können. Unser Test von Fable 5 bestätigt, dass Anthropic Classifier vor das eigentliche Modell schaltet und bei heiklen Eingaben teils auf das Vorgängermodell Opus 4.8 zurückfällt.

Weiterlesen nach der Anzeige

Die zuvor kommunizierten Schutzmaßnahmen seien in einer Vorabprüfung über Tausende Stunden Red-Teaming getestet worden – gemeinsam mit der US-Regierung, dem britischen AI Safety Institute (UK AISI), privaten Organisationen und internen Teams. Die Ergebnisse hätten deutlich über denen früherer Modelle gelegen. Eine vollständig unabhängige Auditierung, etwa durch europäische Forschungseinrichtungen, ist nach derzeitigem Stand allerdings nicht belegt: Eine komplette Offenlegung der Schutzlogik oder der internen Classifier-Architektur gab es nicht. Während Fable 5 mit zusätzlichen Schutzmechanismen für die öffentliche Nutzung versehen wurde, gilt Mythos als restriktivere Variante.

Anthropic räumt ein, dass perfekte Jailbreak-Resistenz für kein Modell erreichbar sei. Zugleich widerspricht das Unternehmen der Auffassung, dass ein einzelner „unwahrscheinlicher Jailbreak den Widerruf eines kommerziellen Modells mit Hunderten Millionen Nutzern rechtfertige“. Würde man diesen Maßstab branchenweit anlegen, käme das einem Stopp neuer Frontier-Modelle gleich.

Die jetzige Anordnung trifft auf ein bereits angespanntes Verhältnis. Anfang März 2026 hatte das US-Verteidigungsministerium Anthropic als „supply chain risk“ eingestuft. In einem aktuellen Blogbeitrag erklärte CEO Dario Amodei, man halte die Einstufung als „supply chain risk“ für rechtlich nicht tragfähig und wolle sie vor Gericht anfechten. Der zugrunde liegende US‑Statut 10 U.S.C. § 3252 sei eng auf spezifische Lieferkettenrisiken bei nationalen Sicherheitssystemen zugeschnitten und verlange, dass das Ministerium darlegt, warum weniger eingriffsintensive Maßnahmen („less intrusive measures“) nicht vernünftigerweise zur Verfügung stehen.

Der Konflikt drehte sich nach Anthropics Darstellung um die Weigerung, Claude uneingeschränkt für massenhafte inländische Überwachung und vollautonome Waffensysteme freizugeben. Ob die aktuelle Exportdirektive primär eine Sicherheitsmaßnahme oder politischer Druck auf einen renitenten Anbieter ist, lässt sich aus den veröffentlichten Quellen nicht beweisen. Plausibel erscheint jedoch, dass der vorangegangene Streit das Verhältnis erheblich verschlechtert und die Eskalation begünstigt hat.

Für hiesige Anbieter ist ein direkt vergleichbarer, einzelmodellbezogener Eingriff in der EU nicht ersichtlich. Während das US-Exportkontrollrecht auf außenwirtschaftliche Zugriffssperren zielt, verfolgt der EU AI Act einen risikobasierten Ansatz mit Marktaufsicht, Transparenz- und Dokumentationspflichten. In Deutschland soll die Bundesnetzagentur die zentrale Marktüberwachungsbehörde werden; den entsprechenden Gesetzentwurf (KI-MIG) hat der Bundestag am 11. Juni 2026 beschlossen, die Zustimmung des Bundesrats steht noch aus. Eine globale Abschaltung eines einzelnen Modells als Maßnahme der Exportkontrolle ist in dieser Logik so nicht vorgesehen.

Lesen Sie auch


(vza)



Source link

Weiterlesen

Entwicklung & Code

App Store: Entwickler dürfen Nutzer künftig beim Kündigen ansprechen


Abseits der viel beachteten Neuerungen rund um KI, Siri und die Betriebssysteme hat Apple im Zuge der Entwicklerkonferenz WWDC auch eine ganze Reihe von Neuheiten und Änderungen für App Store-Entwickler angekündigt. Künftig können erstmals Gruppenkäufe für Abonnenten und entwicklerübergreifende Bundles angeboten werden. Im Mac App Store entfällt die Intel-Pflicht und Entwickler bekommen die Möglichkeit, Nutzer zur Fortsetzung eines Abos zu bewegen. Zudem gibt es mehr Gestaltungsmöglichkeiten für den Auftritt im App Store und neue Auskunftspflichten. Das aus Nutzersicht umstrittenste neue Feature dürfte das sogenannte Retention Messaging werden. Apple bietet neue Werkzeuge in App Store Connect an, um Abonnenten mit Kündigungsabsicht über Apples Abo-Plattform ansprechen zu können. Bereits im März hatte Apple den Analytics-Bereich in App Store Connect massiv erweitert und Entwicklern dabei über 100 neue Metriken für Abonnements und In-App-Käufe an die Hand gegeben. Laut Ankündigung sollen personalisierte Nachrichten und Sonderangebote möglich sein.

Weiterlesen nach der Anzeige

Ganz neue Vermarktungsmöglichkeiten für Apps ergeben sich durch entwicklerübergreifende App-Bundles. Bislang konnte nur ein einzelner Entwickler, der mehrere Apps anbietet, ein vergünstigtes Paket mit mehreren Apps schnüren. Künftig ist das auch für mehrere Entwickler möglich, sodass sich diese bei den Apps zusammentun können. Apple führt zudem ab Winter 2026 Gruppenkäufe für Abonnements ein. Ein einzelner Abonnent kann damit Lizenzen für mehrere Personen in einem einzigen Kauf erwerben.

Apples Abkehr von der Intel-Plattform im neuen macOS Golden Gate schlägt sich auch im Mac App Store nieder: Künftig ist es für App-Entwickler keine Pflicht mehr, Intel-Unterstützung vorzuhalten. Dies dürfte in einigen Fällen dazu beitragen, dass Besitzer eines Intel-Macs eher in die Situation geraten, den Umstieg auf einen Apple-Silicon-Mac erwägen zu müssen – etwa wenn häufig genutzte Apps künftig nicht mehr den Intel-Mac unterstützen. Wann genau Intel-Apps unter Apple Silicon nicht mehr laufen werden und was das Ende von Rosetta 2 für Nutzer bedeutet, erklärt unser Überblick zum Zeitplan des Intel-Supports.

Vereinfachungen und Erweiterungen gibt es beim App-Marketing. Die neuen Betriebssysteme, darunter iOS 27 und macOS 27, stehen Entwicklern bereits als Beta zur Verfügung. In einer neuen Asset Library können Grafiken, Vorschauvideos und Screenshots zentral verwaltet werden. Diese Assets können nun auch unabhängig von einem App-Update zur Prüfung eingereicht werden – und Apple öffnet die Produktseiten-Header für eigenes Bild- und Videomaterial. Neue „Personalized Collections“ sollen maßgeschneiderte App-Empfehlungen für Nutzer ermöglichen. Diese Funktion startet zunächst auf Englisch in den USA.

Und Apples angekündigte erweiterte Jugendschutzfunktionen wirken sich auch auf die Entwickler aus. Diese müssen Social-Feed-Funktionen in ihren Apps künftig angeben. Zudem werden Apps in die neuen Nutzungszeit-Kategorien (Soziale Netzwerke, Unterhaltung, Spiele, Andere) eingruppiert. Der Altersfreigabe-Fragebogen soll hierfür ab Juli aktualisiert werden.

Weiterlesen nach der Anzeige


(mki)



Source link

Weiterlesen

Entwicklung & Code

Homebrew 6.0 sichert Paketquellen ab


Das Homebrew-Team hat Version 6.0.0 des Paketmanagers veröffentlicht. Das Release legt den Schwerpunkt auf Sicherheit, Tempo und Plattformunterstützung. Zu den wichtigsten Neuerungen zählen ein Vertrauensmodell für externe Paketquellen, eine schnellere interne API als neuer Standard und eine Sandbox unter Linux. Hinzu kommen zahlreiche Verbesserungen beim Werkzeug brew bundle sowie eine erste Unterstützung für macOS 27 „Golden Gate“.

Weiterlesen nach der Anzeige

Homebrew ist ein quelloffener Paketmanager für macOS und Linux. Entwickler installieren und aktualisieren damit Kommandozeilenwerkzeuge, Bibliotheken und Anwendungen. Neben den offiziellen Paketquellen lassen sich auch externe Repositories einbinden, sogenannte „Taps“. Über das Windows Subsystem for Linux (WSL) lässt sich Homebrew zudem mit Windows nutzen.

Die wichtigste Neuerung von Homebrew 6.0 ist das Sicherheitskonzept „Tap Trust“. Externe Taps können beliebigen Ruby-Code enthalten, der auf dem lokalen System läuft. Bislang ließen sich solche Paketquellen vergleichsweise unkompliziert einbinden. Künftig müssen Nutzer Taps von Drittanbietern ausdrücklich als vertrauenswürdig markieren, bevor Homebrew deren Code ausführt. Die offiziellen Homebrew-Repositories bleiben standardmäßig freigeschaltet.

Mit dem neuen Modell reagiert das Projekt auf Risiken in der Software-Lieferkette. Übernehmen Angreifer etwa ein Community-Repository, soll die zusätzliche Prüfung verhindern, dass dessen Code unbemerkt auf den Systemen der Nutzer landet. Homebrew liefert dafür neue Befehle zur Verwaltung vertrauenswürdiger Quellen und eine eigene Dokumentationsseite.

Standardmäßig aktiv ist nun auch die interne JSON-API von Homebrew. Sie fasst die Metadaten zu Paketen in einem einzigen Download zusammen und senkt so die Zahl der Netzwerkanfragen. Für Anwender wirkt sich das vor allem durch schnellere Updates und eine geringere Netzwerklast aus. Die Funktion stand seit Homebrew 5.0 optional bereit und wird jetzt zur Voreinstellung.

Auf Linux-Systemen führt Homebrew zudem eine Sandbox auf Basis von Bubblewrap ein. Unter macOS laufen Build-, Test- und Postinstallationsschritte bereits abgeschottet, nun zieht Linux nach. Bubblewrap ist ein schlankes Werkzeug, das Prozesse und Dateizugriffe isoliert. Die Maßnahme soll verhindern, dass Installations- und Build-Prozesse unnötig auf sensible Bereiche des Systems zugreifen.

Weiterlesen nach der Anzeige

Auch bei den Voreinstellungen hat das Projekt nachgebessert und sich dabei auf eine Nutzerumfrage gestützt. Entwickler sehen vor Installationen und Upgrades nun standardmäßig eine Übersicht der geplanten Änderungen und Abhängigkeiten. Erst nach einer Bestätigung führt Homebrew die Aktionen aus.

Darüber hinaus arbeitet Homebrew an vielen Stellen schneller: Es gibt Optimierungen beim Programmstart, eine parallele Verarbeitung einzelner Upgrade-Schritte und einen geringeren Ruby-Overhead. Das Kommando brew leaves, das eigenständig installierte Pakete ohne abhängige weitere Pakete auflistet, soll rund 30 Prozent schneller arbeiten.

Deutlich ausgebaut hat das Projekt brew bundle, mit dem sich komplette Entwicklungsumgebungen über eine Brewfile beschreiben lassen. Pakete installiert das Werkzeug nun standardmäßig parallel. Außerdem unterstützt es zusätzliche Ökosysteme wie npm und den kubectl-Plugin-Manager Krew. Unter Windows arbeitet brew bundle jetzt auch mit dem Microsoft-Paketmanager Winget zusammen. Hinzu kommen erweiterte Funktionen zum Aufräumen installierter Pakete.

Im Sicherheitsbereich verweist das Projekt auf drei behobene Schwachstellen. Darunter fallen ein Problem bei Download-Weiterleitungen sowie Lücken im macOS-Installer, die unter bestimmten Umständen eine lokale Rechteausweitung erlaubten. Darüber hinaus filtert Homebrew sensible Umgebungsvariablen nun strenger. Eine neue Dokumentationsseite beschreibt zudem die Maßnahmen gegen Risiken in der Software-Lieferkette.

Für Entwickler kommen mehrere Werkzeuge hinzu. Das neue Kommando brew exec erinnert an npx aus der Node.js-Welt und führt Programme in der Umgebung eines Homebrew-Pakets aus. Ebenfalls neu ist brew vulns, das installierte Pakete auf bekannte Sicherheitslücken prüft. Es liegt vorerst als separates Homebrew-Tap vor.

Technisch interessant ist außerdem das neue „Install Steps Framework“. Paketbetreuer können bestimmte Installationsschritte künftig als reine Daten beschreiben, statt sie als ausführbaren Ruby-Code zu hinterlegen. Für einfache Aufgaben wie das Anlegen von Verzeichnissen, das Verschieben von Dateien oder das Erzeugen symbolischer Links muss Homebrew dadurch weniger Code herunterladen und ausführen. Das verspricht Vorteile bei Sicherheit, Wartbarkeit und Tempo.

Mit Homebrew 6.0 unterstützt der Paketmanager erstmals macOS 27 „Golden Gate“ in Grundzügen. Gleichzeitig kündigt das Team das schrittweise Aus für Intel-Macs an, da Apple mit macOS 27 keine Intel-Systeme mehr unterstützt. Ab September 2026 will Homebrew keine neuen vorkompilierten Pakete mehr für macOS auf Intel-Prozessoren bereitstellen. Ein Jahr später soll die Unterstützung vollständig wegfallen.

Detaillierte Informationen zum neuen Release finden sich auf der Webseite des Projekts.


(fo)



Source link

Weiterlesen

Beliebt