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

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.

Taps müssen sich künftig als vertrauenswürdig erweisen

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.

Neue API als Standard, Sandbox für Linux

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.

Bessere Standardeinstellungen und mehr Tempo

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.

Neue Befehle und ein deklaratives Installationsmodell

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.

macOS 27 in Sicht, Intel-Support läuft aus

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)

Mit OpenSharing hat das Unternehmen Databricks ein offenes Protokoll vorgestellt, das den sicheren Austausch von Daten und KI-Assets wie Modellen, Agent-Skills und unstrukturierten Daten über Plattform-, Cloud- und Organisationsgrenzen hinweg standardisieren soll. Das Projekt wird ab sofort von der Linux Foundation als Open-Source-Community-Projekt gehostet und steht auf GitHub zur Verfügung.

Umfassender und standardisierter Datenaustausch

OpenSharing baut auf dem von Databricks bereits 2021 eingeführten Delta Sharing auf, einem Open-Source-Protokoll für den sicheren Datenaustausch. Während sich Delta Sharing auf strukturierte Daten in Tabellenformaten wie Delta Lake konzentrierte, erweitert OpenSharing das unterstützte Spektrum an Daten und Formaten erheblich: Neben tabellarischen Daten lassen sich nun auch KI-Modellartefakte, Agent-Skills – also Funktionen und Tools für autonome Agenten – sowie unstrukturierte Daten wie Dokumente oder Mediendateien über ein einheitliches Protokoll teilen. Das Protokoll orientiert sich zudem am Zero-Copy-Prinzip: Daten werden nicht repliziert, sondern Clients greifen direkt auf den Quellspeicher zu.

Technisch definiert OpenSharing standardisierte APIs für Discovery, Authorization und Access. Laut den Projektverantwortlichen können Nutzer damit ein einheitliches Schnittstellenset ansprechen, unabhängig von der dahinterliegenden Plattform. Die konkreten Authentifizierungsmechanismen – etwa ob OAuth2 oder OIDC zum Einsatz kommen – sind in den bisherigen Veröffentlichungen nicht im Detail dokumentiert. Die vollständige Spezifikation soll jedoch über das GitHub-Repository zugänglich gemacht werden. Aus der Delta-Sharing-Architektur ist bekannt, dass ein Sharing-Server als Kontrollebene fungiert und der eigentliche Datenzugriff über vorab signierte URLs auf Cloud- oder Objektspeicher läuft.

Eine wesentliche Neuerung gegenüber Delta Sharing ist der Support für Apache-Iceberg-Clients. Provider können damit über ein einzelnes Protokoll sowohl Delta- als auch Iceberg-basierte Empfänger bedienen. Betreiber von Lakehouse-Architekturen profitieren dadurch von einer reduzierten Fragmentierung im Open-Data-Ökosystem: Engines wie Spark, Trino oder Flink mit Iceberg-Support erhalten einen standardisierten Zugriffspfad auf geteilte Assets, ohne dafür auf proprietäre Adapter zurückgreifen zu müssen.

Linux Foundation übernimmt Governance

Die Linux Foundation stellt für OpenSharing herstellerneutrale Governance-Strukturen bereit. Laut Jim Zemlin, CEO der Linux Foundation, soll OpenSharing das „kritische Bedürfnis nach einem gemeinsamen, herstellerneutralen Framework, das Organisationen den sicheren und interoperablen Austausch von KI-Assets über Plattformen und Ökosysteme hinweg ermöglicht“, erfüllen. Das Projekt reiht sich damit in andere Infrastrukturstandards unter dem Dach der Linux Foundation ein, bei denen neutrale Governance für breitere Akzeptanz sorgen soll, darunter etwa Kubernetes, RISC-V und MCP (letzteres über die Agentic AI Foundation, einer Stiftung innerhalb der Linux Foundation).

Delta Sharing hat nach Einschätzung von Databricks-Mitgründer und CTO Matei Zaharia bereits bewiesen, dass die Branche offene Standards bevorzuge. OpenSharing werde dieses Prinzip auf den gesamten KI-Stack und das plattformübergreifende Ökosystem erweitern.

Relevanz für europäische Unternehmen

Bei Unternehmen mit strengen Datenschutz- und Souveränitätsanforderungen – etwa in regulierten Branchen wie dem europäischen Bankwesen, Gesundheitswesen oder der öffentlichen Verwaltung – dürfte OpenSharing auf Interesse stoßen. Durch das Zero-Copy-Prinzip verbleiben Daten physisch in der bestehenden Speicherumgebung, sei es ein eigenes Rechenzentrum oder eine europäische Cloud. Cloud-basierte KI-Dienste greifen über das Protokoll zu, ohne dass Daten bewegt werden müssen. Das erleichtert die Einhaltung von DSGVO-Anforderungen und Daten-Minimierungsansätzen, weil für alle Beteiligten nicht mehr in jedem Fall separate Kopien angelegt werden müssen.

Zum Projektstart positionieren sich bereits zahlreiche Unternehmen als Unterstützer. Atlassian hat Data Shares in Atlassian Analytics eingeführt und nutzt OpenSharing, um Zugriff auf Cloud-Daten in großem Maßstab zu ermöglichen. SAP setzt in der Business Data Cloud auf das Protokoll, Stripe integriert es nativ in die Stripe Data Pipeline und die London Stock Exchange Group (LSEG) bindet es in ihre „LSEG Everywhere“-Strategie ein.

Dass mit SAP ein zentraler europäischer Softwareanbieter das Protokoll früh übernimmt und auch Storage-Hersteller wie NetApp und HPE – mit starker Präsenz in europäischen Rechenzentren – ihre Unterstützung angekündigt haben, unterstreicht die Ausrichtung auf regulierte On-Premise-Szenarien. OpenSharing positioniert sich damit als offene Alternative zu den proprietären Datenmarktplätzen der großen Hyperscaler.

(map)

Anthropic reagiert auf die Kritik an den Schutzmechanismen seines neuen KI-Modells Fable 5. Das Unternehmen will umstrittene, verborgene Sicherheitsmaßnahmen künftig sichtbar machen und entschuldigt sich ausdrücklich für deren bisherige Umsetzung. Konkret geht es um Schutzmechanismen gegen sogenanntes Distillation – also den Versuch, die Ausgaben eines leistungsfähigen Sprachmodells zum Training konkurrierender KI-Systeme zu nutzen.

Die Kontroverse entzündete sich an einem Schutzverhalten von Fable 5, bei dem das Modell verdeckt auf Distillation-Anfragen reagierte. Anthropic sah ursprünglich einen unsichtbaren Mechanismus vor, der solche Versuche zur Modellentwicklung im Hintergrund erkennt und die Antworten gezielt verändert oder verschlechtert. Die Nutzer sollten davon nichts mitbekommen. Forscher und Entwickler kritisierten das als intransparent und warnten, dass solche verdeckten Eingriffe auch Tests und wissenschaftliche Untersuchungen des Modells verfälschen.

Fable 5 fällt künftig sichtbar auf Opus 4.8 zurück

In einem Beitrag auf X kündigt Anthropic nun eine Kurskorrektur an. Künftig behandelt das Unternehmen erkannte Distillation-Anfragen sichtbar. Statt Antworten heimlich zu verändern, fällt Fable 5 in solchen Fällen auf das ältere Modell Claude Opus 4.8 zurück – genau wie es bereits bei den Schutzmaßnahmen für Cybersecurity und Biologie der Fall ist. Die Nutzer sollen dabei jedes Mal einen entsprechenden Hinweis sehen.

Für API-Kunden will Anthropic zudem den Grund einer Ablehnung explizit zurückgeben. Ein serverseitiger Fallback für API-Anfragen soll in den kommenden Tagen folgen. Damit lässt sich künftig erkennen, ob eine Antwort von Fable 5 oder vom Fallback-Modell stammt.

Anthropic räumt die falsche Abwägung ein

Das Unternehmen gibt zu, mit dem ursprünglichen Ansatz falsch gelegen zu haben. Sichtbare Schutzmechanismen lassen sich zwar leichter analysieren und gezielt umgehen, weshalb ihre Absicherung mehr Zeit kostet. Unsichtbare Schutzmaßnahmen lassen sich dagegen enger auf bestimmte Szenarien zuschneiden und verursachen weniger Fehlalarme. Aus diesem Grund habe man sich zunächst für den verdeckten Ansatz entschieden, um Fable 5 schnell und sicher bereitzustellen.

Rückblickend sei das die falsche Entscheidung gewesen, schreibt Anthropic. Die Nutzer sollten nachvollziehen können, welche Schutzmaßnahmen aktiv sind und warum. Dafür entschuldigt sich das Unternehmen ausdrücklich.

Mehr Transparenz, vorerst mehr Fehlalarme

Die Umstellung hat allerdings Nebenwirkungen. Um die Systeme trotzdem vor Jailbreaks abzusichern, müssen die zugrunde liegenden Klassifikatoren zunächst konservativer arbeiten. Das führt vorübergehend zu mehr Fehlklassifikationen.

Solche False Positives entstehen, wenn das Modell harmlose Anfragen fälschlich als riskant einstuft. Genau hier setzt ein Großteil der bisherigen Kritik an.

Kritik aus der Sicherheitscommunity

Die Ankündigung folgt nur wenige Tage auf heftige Kritik von Sicherheitsforschern an Fable 5. Mehrere Experten beklagen, dass die Cybersecurity-Schranken des Modells nicht nur brisante Anfragen erfassen, sondern auch alltägliche Aufgaben aus Softwareentwicklung und IT-Sicherheit. Genannt wurden unter anderem Code Reviews, das Schreiben sicheren Codes, Schwachstellenanalysen, Incident Response oder schlicht das Lesen sicherheitsrelevanter Fachartikel.

Fable 5 ist die öffentlich verfügbare Variante von Anthropics neuem Spitzenmodell Mythos 5. Letzteres bringt keine vorgeschalteten Schutzmechanismen für Cybersecurity, Biologie, Chemie und Distillation mit.

Anthropic justiert die Cyber- und Bio-Filter nach

In seiner Stellungnahme verspricht Anthropic auch Änderungen an den Cyber- und Bio-Safeguards. Die entsprechenden Klassifikatoren stelle man derzeit so ein, dass sie seltener bei harmlosen Anfragen anschlagen. Nutzer, die eine Fehlklassifikation vermuten, sollen diese melden – über Feedback-Funktionen in Claude Code und Claude.ai sowie über ein Einspruchsformular für API-Anfragen.

Ob die Anpassungen ausreichen, bleibt abzuwarten. An den Schutzmaßnahmen selbst hält Anthropic ausdrücklich fest – diese hatten die Kritiker allerdings auch nicht infrage gestellt.

(fo)