Funktioniert Homebrew in China? Data Residency, ICP & Grenztransfer-Regeln
Homebrews öffentliche Formulae sind Open Source, Erreichbarkeit ist also nicht die eigentliche Frage. Die Residency- und Lieferketten-Frage ist Ihr privates Tap — internes Tooling, Install-Logik und kompilierte Bottles —, das standardmäßig auf einem offshore gelegenen Git- und Artefakt-Host sitzt. Der Hebel: das Tap und den Bottle-Speicher im Inland selbsthosten.
Funktioniert Homebrew in China?
Homebrews öffentliche Formulae sind Open Source auf GitHub, ob eine Festland-Maschine brew install ausführen kann, ist also eine Erreichbarkeitsangelegenheit, nicht die Compliance-Frage. Die Residency- und Lieferketten-Frage ist Ihr privates Tap — das Git-Repository, das Ihr internes Tooling, Ihre Install-Logik und manchmal Zugangsdaten beschreibt — und die kompilierten Bottles, die Ihr China-Build zieht. Standardmäßig leben die auf einem offshore gelegenen Git- und Artefakt-Host; halten Sie dies maßvoll, denn die Exponierung ist die proprietäre Lieferkette, nicht der Open-Source-Katalog.
Homebrews eigene Doku macht den Hebel konkret. Ein Tap, sagt sie, „can be created by anyone“ und „is usually a Git repository available online, but you can use anything as long as it's a protocol that Git understands, or even just a directory with files in it“ — und ein Tap kann seine eigenen Bottles bedienen, da die Bottle-Root „optionally contains the URL root used to determine bottle URLs“. Sie können das private Tap also in Ihrem eigenen inländischen Git-Repository hosten und seine Bottles in einem inländischen Artefakt-Speicher halten. Wo dieses private Tap oder seine Bottles personenbezogene Information tragen, ist es ein grenzüberschreitender Transfer nach PIPL (Artikel 38–40), sie offshore zu halten, und für einen CIIO oder Handler mit hohem Volumen müssen die Daten in China bleiben (Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)). Ein China-gerichtetes Paket-Portal, das Ihre Festland-Entwickler erreichen, würde zusätzlich eine ICP-Beian-Pflicht tragen.
Dies ist eine Risikokarte für die private Hälfte, kein Urteil — Homebrew funktioniert, und welche Pflichten greifen, hängt von Ihrer Rechtsperson, Ihren Datenmengen und dem, was Ihr Tap tatsächlich hält, ab. Unser China-Team kann Ihre Exponierung mit Ihnen kartieren →
Compliance-Momentaufnahme
- ! Homebrews öffentliche Formulae sind Open Source auf GitHub — Erreichbarkeit ist nicht die Achse
- ! Ein privates Tap kodiert Ihr internes Tooling-Inventar und Ihre Install-Logik — proprietär
- ! Standardmäßig sitzen das private Tap und seine kompilierten Bottles auf offshore gelegenen Git- und Artefakt-Hosts
- ! Ein China-Build, der dieses offshore gelegene private Tap zieht, betreibt seine Lieferkette über die Grenze
- ✓ Das private Tap in einem inländischen Git-Repo und Bottle-Speicher selbsthosten — bleibt ansässig
Was die offizielle Homebrew-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| Ein Homebrew-Tap ist ein Git-Repository, das Sie selbst erstellen und hosten — das ist der inländische Hebel. Homebrews Tap-Authoring-Doku gibt an, ein Tap „is usually a Git repository available online, but you can use anything as long as it's a protocol that Git understands, or even just a directory with files in it“, und dass Taps „can be created by anyone to provide their own formulae, casks and/or external commands to any Homebrew user“. Der standardmäßige Tap-Befehl „assumes a repository on GitHub“, aber „the two-argument form accepts any URL supported by Git“ — ein privates Tap kann also in Ihrem eigenen inländischen Git-Repository leben statt auf einem offshore gelegenen Host. | Homebrew — How to Create and Maintain a Tap, and Taps (docs.brew.sh), abgerufen 2026-10-13 |
Bottles sind Ihre kompilierten Binaries, und ein Tap kann sie aus einer Speicher-Root bedienen, die Sie wählen. Homebrew definiert ein Bottle schlicht — „Bottles are simple gzipped tarballs of compiled binaries“ —, und seine Bottle-DSL „optionally contains the URL root used to determine bottle URLs“, was „useful for taps that wish to provide bottles for their formulae“ ist. Standardmäßig werden Homebrews eigene Core-Bottles aus GitHub Packages (offshore) bedient, aber weil die Bottle-root_url Ihre ist, kann der Artefakt-Speicher eines privaten Taps im Inland platziert werden. | Homebrew — Bottles (docs.brew.sh), abgerufen 2026-10-13 |
| Ein privates Tap oder seine Bottles offshore zu halten ist ein grenzüberschreitender Transfer, wo sie personenbezogene Daten tragen. Die Formulae eines privaten Taps können Zugangsdaten, Config oder Test-Fixture-Datensätze einbetten; wenn dieser Inhalt personenbezogene Information ist und er auf einem offshore gelegenen Git- oder Artefakt-Host ruht, ist es ein grenzüberschreitender Transfer nach PIPL Artikel 38–40, ihn ins Ausland zu bewegen — was Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus (eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder Zertifizierung) erfordert. Die Pflicht fällt auf Sie, den Handler, nicht auf Homebrew. | PIPL Artikel 38–40 (Datenausfuhr-Mechanismen und gesonderte Einwilligung); abgerufen 2026-10-13 |
| Für einen CIIO oder Handler mit hohem Volumen müssen in China erzeugte personenbezogene Information und wichtige Daten im Festland gespeichert werden. Artikel 39 (vormals Artikel 37) des Cybersicherheitsgesetzes — die Novelle von 2025, in Kraft seit 1. Januar 2026, nummerierte den Artikel zur Datenlokalisierung von 37 auf 39 um, Substanz unverändert — verlangt inländische Speicherung, mit einer Sicherheitsbewertung vor jeder Ausfuhr. Ein privates Tap und ein Bottle-Speicher, die offshore gehostet werden, können diese Pflicht für die regulierten Daten, die sie halten, strukturell nicht erfüllen; ein selbstgehostetes, inländisches Tap und ein Artefakt-Speicher können es. | Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37), in Kraft 2026-01-01; abgerufen 2026-10-13 |
Quellen vom 21YunBox Compliance-Team am 13. Oktober 2026 geprüft.
Für ein Festlandchina-Engineering-Team ist das Ehrlichste, das man zuerst zu Homebrew klären sollte, was die Frage nicht ist. Homebrews öffentliche Formulae und Casks sind Open Source, veröffentlicht in Git-Repositories auf GitHub, und ob eine Build-Maschine in Schanghai brew install ausführen und ein Community-Paket ziehen kann, ist eine betriebliche Angelegenheit — ein Mirror oder Cache beantwortet sie, und es ist keine Compliance-Frage. Die Compliance-Frage lebt eine Schicht tiefer, auf der Hälfte, die eine Erreichbarkeitsprüfung nie erreicht: Ihr privates Tap. Ein Tap ist Homebrews Verteilungseinheit für Ihre eigenen Formulae und Casks, und ein privates kodiert Ihr internes Tooling — welche proprietären Tools Ihr China-Build und Provisioning installieren, in welchen Versionen, von wo, mit welchen Schritten und manchmal die Zugangsdaten, um sie zu holen. Daneben sitzt ein Bottle-Speicher: die kompilierten Binaries (Bottles), die Ihr Build zieht. Dieses private Tap und der Bottle-Speicher sind Ihre Software-Lieferkette, und standardmäßig leben sie dort, wo immer Sie sie hosten — was für die meisten Teams ein offshore gelegener Git-Host und ein offshore gelegener Artefakt-Speicher ist. Wo dieser proprietäre Code und diese Artefakte zur Ruhe kommen und was Ihr China-Build bei jedem Lauf über die Grenze zieht, ist die ganze Frage — und weil ein Homebrew-Tap nur ein Git-Repository ist, das Sie selbst hosten, dürfen Sie es entscheiden.
Halten Sie dies maßvoll. Homebrews öffentlicher Katalog ist Open Source und trägt keine eigene Residency-Frage; dies ist keine große Data-Residency-Behauptung über brew install. Es ist eine enge, spezifische über das private Tap und den Bottle-Speicher, von denen eine China-Build- oder Provisioning-Pipeline abhängt.
Homebrew in China auf einen Blick
| Worüber es entscheidet | In Homebrews eigenen Worten — und Chinas Recht |
|---|---|
| Öffentliche Formulae sind Open Source — nicht die Achse | Homebrews öffentliche Formulae und Casks sind Open Source auf GitHub. Seine Doku merkt an, die standardmäßige „one-argument form assumes a repository on GitHub“, während „the two-argument form accepts any URL supported by Git“. Community-Pakete zu ziehen ist eine Erreichbarkeits- und Mirror-Frage — betrieblich nützlich, aber nicht dort, wo die Compliance-Exponierung ist. |
| Ihr privates Tap ist proprietäre Lieferkette | Die kennzeichnende Hälfte, die eine Erreichbarkeitsprüfung nie sieht. Ein privates Tap ist das Git-Repository, das Ihr internes Tooling beschreibt — welche proprietären Tools Ihr China-Build installiert, ihre Versionen und Quellen, die Install-Logik und manchmal Zugangsdaten oder Config, um sie zu holen. Das ist geschäftsgeheimnishaftes Lieferketten-Detail, und seine kompilierten Bottles sind Ihre eigenen Binaries. Wo sie leben, ist eine Residency-Frage, keine Geschwindigkeitsfrage. |
| Offshore standardmäßig | Standardmäßig sitzt ein privates Tap auf einem offshore gelegenen Git-Host und seine Bottles auf einem offshore gelegenen Artefakt-Speicher; Homebrews eigene Core-Bottles werden, zur Referenz, aus GitHub Packages bedient. Ihre proprietären Formulae, Build-Logik und Binaries — plus alle Zugangsdaten, die die Formulae tragen — ruhen also im Ausland, es sei denn, Sie platzieren sie anderswo. |
| Der China-Build zieht über die Grenze | Wenn ein Festland-Build- oder -Provisioning-Lauf Ihr privates Tap auflöst und seine Bottles von einem offshore gelegenen Host herunterlädt, überschreitet die Abhängigkeits-Lieferkette Ihres China-Deployments bei jedem Lauf die Grenze — eine Frage der Provenienz, Integrität und Residency proprietären Materials, die keine „kann es das Paket auflösen“-Prüfung misst. |
| Residency & Grenztransfer | Wo dieses private Tap oder seine Bottles personenbezogene Information oder reguliertes Material tragen, ist es ein grenzüberschreitender Transfer nach PIPL Artikel 38–40, es auf einem offshore gelegenen Host zu halten — Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus (eine CAC-Sicherheitsbewertung, der CAC-Standardvertrag oder Zertifizierung). Für einen Betreiber kritischer Informationsinfrastruktur oder Handler mit hohem Volumen verlangt Artikel 39 (vormals Artikel 37) des Cybersicherheitsgesetzes, dass in China erzeugte personenbezogene Information und wichtige Daten im Festland gespeichert werden. |
| Selbsthosting ist der Hebel | Weil ein Tap „just a Git repository“ ist, ist der rechtmäßige Hebel einfach: das private Tap in Ihrem eigenen inländischen Git-Repository hosten und seine Bottles aus einem inländischen Artefakt-Speicher bedienen (ein Tap kann seine eigene Bottle-root_url setzen), sodass proprietärer Code, Build-Logik und Binaries ansässig bleiben und die China-Lieferkette im Inland bleibt — der 21YunBox Optimizer vor dem, was Sie bereits betreiben. |
Was ein privates Tap tatsächlich hält — und warum es die Achse ist
Ein Homebrew-Tap ist kein Datensatz, wie eine Anwendungsdatenbank einer ist; es ist eine Beschreibung einer Software-Lieferkette, und genau darum ist es eine Residency-Frage statt einer Geschwindigkeitsfrage. Homebrews Dokumentation ist ausdrücklich, dass ein Tap etwas ist, das Sie selbst erstellen und hosten: Taps „can be created by anyone to provide their own formulae, casks and/or external commands to any Homebrew user“, und „a tap is usually a Git repository available online, but you can use anything as long as it’s a protocol that Git understands, or even just a directory with files in it“. Der brew tap-Befehl, in den Worten der Doku, „adds repositories that Homebrew can use for formulae, casks and external commands“.
Für ein Unternehmen ist ein privates Tap, wo die Sensibilität sitzt. Seine Formulae und Casks zählen Ihr internes Tooling auf — die proprietären Tools, die Ihre China-Build- und Provisioning-Pipelines installieren, ihre Versionen, die URLs, von denen sie geholt werden, und die genauen Install-Schritte —, die zusammen geschäftsgeheimnishaftes Detail darüber sind, wie Ihre Systeme gebaut werden. Formulae und Casks tragen routinemäßig Konfiguration und bisweilen die Zugangsdaten oder Tokens, die nötig sind, um eine interne Download-Quelle zu erreichen. Und die Bottles des Taps — die Homebrew schlicht definiert: „Bottles are simple gzipped tarballs of compiled binaries“ — sind Ihre eigene kompilierte interne Software. Ein Tap kann diese Bottles sogar aus einem Speicherort bedienen, den Sie wählen: Die Bottle-DSL „optionally contains the URL root used to determine bottle URLs“, und das ist „useful for taps that wish to provide bottles for their formulae“. Die Residency-Karte hat also zwei Schichten: die proprietäre Lieferketten-Beschreibung im Tap und die kompilierten Artefakte, auf die es zeigt.
Die Türen: Lieferkette, Residency, Grenztransfer und ICP
Richten Sie einen China-Build auf ein privates Tap und einen Bottle-Speicher, die offshore leben, und die erste Exponierung öffnet sich — und es ist eine Lieferketten-Exponierung. Die Abhängigkeits-Lieferkette Ihres China-Deployments läuft nun über die Grenze: Bei jedem Build- oder Provisioning-Lauf löst Festland-Infrastruktur ein offshore gelegenes Tap auf und lädt Binaries von einem offshore gelegenen Artefakt-Host herunter. Das ist eine Frage, welcher proprietäre Code in Ihre China-Systeme gelangt, mit welcher Provenienz und Integrität, und wo er gespeichert wird — nichts davon kann eine „kann das Paket auflösen“-Prüfung sehen.
Wo dieses private Tap oder seine Bottles personenbezogene Information tragen — eine an eine Person gebundene Zugangsdatenangabe, eine Config mit Kontaktdaten, Test-Fixtures mit echten Datensätzen —, ist es ein grenzüberschreitender Transfer (数据出境), es auf einem offshore gelegenen Host zu halten. Die Pflicht landet bei Ihnen, dem Handler: PIPL Artikel 38–40 verlangen einen Transfermechanismus und eine gesonderte Einwilligung, um solche Daten offshore zu senden. Und wenn Ihre Organisation kritische Informationsinfrastruktur betreibt oder personenbezogene Information in großem Maßstab verarbeitet, verlangt Artikel 39 (vormals Artikel 37 — die Novelle des Cybersicherheitsgesetzes von 2025, in Kraft seit 1. Januar 2026, nummerierte den Artikel zur Datenlokalisierung von 37 auf 39 um, seine Substanz unverändert) des Cybersicherheitsgesetzes, dass in China erzeugte personenbezogene Information und wichtige Daten im Festland gespeichert werden. Halten Sie dies maßvoll: Für ein privates Tap ist der Gehalt an personenbezogener Information meist beiläufig statt zentral — die primäre Exponierung ist der proprietäre Code und die Zugangsdaten, mit Residency-Pflichten, die greifen, wo personenbezogene Daten tatsächlich vorhanden sind.
Eine weitere Tür ist bedingt. Wenn Sie eine China-gerichtete Oberfläche um das Tap aufstellen — ein internes Paket-Portal oder eine Self-Service-Artefakt-Site, die Ihre Festland-Entwickler über das öffentliche Internet erreichen —, ist diese Oberfläche ein Internet-Informationsdienst und trägt eine ICP-Beian-Pflicht (备案), an Festland-Hosting gebunden. Ein Tap, das privat von Ihrer Build-Infrastruktur konsumiert wird, löst das nicht von allein aus; ein öffentlich zugängliches kann es.
Warum eine Erreichbarkeitsprüfung das verfehlt
Eine Sonde aus China kann brew install ausführen, zusehen, wie ein Paket herunterlädt, und schließen „es funktioniert“. Diese Antwort ist nebensächlich. Die Exponierung ist nicht, ob der Client auflösen und holen kann — ein Mirror oder Cache klärt das. Es ist, wo Ihr privates Tap und seine Bottles leben und was die Grenze überschreitet, wenn Ihr China-Build sie zieht: das proprietäre Tooling-Inventar und die Install-Logik im Tap, die Zugangsdaten, die seine Formulae tragen können, und die kompilierten Binaries im Bottle-Speicher. Ein Erreichbarkeitstest sieht nichts davon. Er kann Ihnen nicht sagen, dass Ihre interne Lieferkette in einem Repository auf einem offshore gelegenen Git-Host beschrieben ist, dass Ihre kompilierten Artefakte in einem offshore gelegenen Speicher sitzen oder ob irgendwelche personenbezogenen Daten mitritten.
Es gibt eine für Paket-Tooling spezifische Falle: Die öffentliche Registry bloß erreichbar zu machen — einen Mirror oder Cache aufzustellen, sodass Community-Pakete schnell installieren — tut nichts für Residency, weil Ihr privates Tap und Ihre Artefakte weiterhin offshore sind. Den Open-Source-Katalog zu mirrorn und Ihre proprietäre Lieferkette im Inland zu halten, sind zwei verschiedene Dinge. Das ist die wettbewerbssichere zweite Hälfte der Frage, und darum ist das private Tap und den Bottle-Speicher im Inland zu halten — nicht bloß Installationen schnell zu machen — die Antwort.
Der rechtmäßige Pfad — kartieren, lokalisieren, ausliefern
Es gibt einen rechtskonformen Weg, ein privates Homebrew-Tap für ein Festlandchina-Team zu betreiben, und weil ein Tap nur ein Git-Repository ist und Bottles aus einer Root-URL bedient werden können, die Sie wählen, sitzt er auf dem Tooling, das Sie bereits nutzen — kein Neuaufbau, keine Migration von Homebrew weg.
Zuerst kartieren: Unser China-Compliance-Team inventarisiert Ihr privates Tap — welche Ihrer Formulae und Casks proprietäres internes Tooling beschreiben, ob sie Zugangsdaten oder Config einbetten, wo das Tap-Repository und seine Bottles heute gehostet sind und was Ihr China-Build und Provisioning tatsächlich über die Grenze ziehen. Wir bauen das technische Bild; die rechtlichen Schlüsse werden mit Rechtsbeistand geklärt.
Dann lokalisieren: das private Tap in einem inländischen Git-Repository hosten und seine Bottles aus einem inländischen Artefakt-Speicher bedienen (die Bottle-root_url zeigt, wohin Sie wählen), sodass Ihr proprietärer Code, Ihre Build-Logik, Zugangsdaten und kompilierten Binaries auf Festland-Boden zur Ruhe kommen und die Lieferkette Ihres China-Builds im Inland bleibt. Wo personenbezogene Information wirklich vorhanden ist, die Mitteilung und gesonderte Einwilligung einholen und einen rechtmäßigen Transfermechanismus nur nutzen, wo ein Transfer wirklich nötig ist; minimieren, was die Grenze überschreitet. Lokalisieren bedeutet, eine rechtmäßige, inländische Lieferkette aufzustellen — niemals eine Route, die das proprietäre Material dennoch offshore verschifft, und niemals irgendeine Form der Umgehung.
Dann ausliefern: Wenn Sie eine China-gerichtete Oberfläche um das Tap freilegen — ein internes Paket-Portal oder eine Artefakt-Site, die Ihre Festland-Entwickler erreichen —, ist es ein Internet-Informationsdienst, es trägt also eine ICP-Beian-Pflicht und braucht rechtskonforme, inländische Auslieferung. 21YunBox liefert sie im Inland aus — der 21YunBox Optimizer — vor dem, was Sie bereits betreiben. 21YunBox nutzt oder empfiehlt niemals Umgehung jeglicher Art — wir halten im Inland, was das Gesetz sagt, dass es bleiben muss, liefern den Rest rechtskonform aus dem Festland heraus und bewegen reguliertes Material niemals heimlich über die Grenze. 21YunBox ist eine Compliance-Overlay und ein Partner für den Homebrew-Workflow, den Sie bereits betreiben, kein Wettbewerber zu ihm.
Nichts davon ist ein Urteil, dass Homebrew in China „gesperrt“ oder „illegal“ ist — es funktioniert klar, und sein öffentlicher Katalog ist Open Source. Es ist eine Residency-und-Lieferketten-Karte für die private Hälfte, und welche Pflichten Ihren Fall treffen, hängt von Ihrer Rechtsperson, Ihrer Rolle nach chinesischem Recht, Ihren Datenmengen und davon ab, was Ihr privates Tap tatsächlich hält — es lohnt sich, die Einzelheiten mit Rechtsbeistand zu klären, bevor die Lieferkette Ihres China-Builds davon abhängt.
Compliance-Einschätzung anfordern →
Weiterführend:
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Cybersicherheitsgesetz (Datenlokalisierung, Artikel 39)
- Chinas Gesetz zum Schutz personenbezogener Daten (PIPL)
- So erhalten Sie eine ICP-Beian für China
Häufige Fragen
Kann ich Homebrew-Pakete in China installieren?
Im Allgemeinen ja — Homebrews öffentliche Formulae und Casks sind Open Source auf GitHub, und ob eine Festland-Build-Maschine Community-Pakete auflösen und herunterladen kann, ist eine betriebliche Erreichbarkeitsangelegenheit, bei der ein Mirror oder Cache helfen kann. Das ist jedoch nicht die Compliance-Frage, und diese Seite führt nicht damit. Die Frage, die für ein Unternehmen zählt, ist, wo Ihr privates Tap und seine kompilierten Bottles leben und was Ihr China-Build über die Grenze zieht, denn das ist Ihre proprietäre Software-Lieferkette.
Ist Homebrew nicht alles Open Source — was ist also die Residency-Exponierung?
Der öffentliche Katalog ist Open Source und trägt keine eigene Residency-Frage, halten Sie das Anliegen also eng gefasst. Die Exponierung ist das private Tap, das Sie für internes Tooling betreiben: das Git-Repository, das aufzählt, welche proprietären Tools Ihr China-Build installiert, in welchen Versionen und von wo, die Install-Logik und manchmal Zugangsdaten, um eine interne Quelle zu erreichen — plus die kompilierten Bottles, auf die dieses Tap zeigt. Wenn dieses Tap und seine Bottles auf einem offshore gelegenen Git- und Artefakt-Host sitzen, sind die Lieferkette und der proprietäre Code Ihres China-Deployments offshore, und alle personenbezogenen Daten, die sie tragen, sind ein grenzüberschreitender Transfer nach PIPL.
Kann 21YunBox helfen, ein privates Homebrew-Tap rechtskonform für China zu betreiben?
Ja. Unser China-Team kartiert, was Ihr privates Tap hält — welche Formulae und Casks proprietär sind, ob sie Zugangsdaten einbetten und wo das Tap-Repository und seine Bottles heute gehostet sind — und hilft Ihnen dann, das Tap in einem inländischen Git-Repository zu hosten und seine Bottles aus einem inländischen Artefakt-Speicher zu bedienen, sodass proprietärer Code und Build-Logik ansässig bleiben. Weil ein Tap nur ein Git-Repository ist und Bottles eine Root-URL nutzen, die Sie setzen, braucht dies keinen Neuaufbau und keine Migration von Homebrew weg. Jedes China-gerichtete Paket-Portal wird dann rechtskonform, im Inland, ausgeliefert. Kontaktieren Sie uns, um Ihren konkreten Fall durchzugehen.
