Ein selbst gehosteter Go-Modul-Proxy führt keinerlei Überprüfungen durch – und Angreifer wissen das

Wichtigste Erkenntnisse

• Ein Go-Modul-Proxy dient dazu, Dateien bereitzustellen, und nicht dazu, zu beurteilen, ob diese Dateien sicher ausgeführt werden können.
• Ein einzelnes Zeichen in Ihrer GOPROXY-Zeichenkette entscheidet darüber, ob ein ausgefallener Proxy lautstark ausfällt oder die Builds stillschweigend ins öffentliche Internet weiterleitet.
• GOPRIVATE überspringt die öffentliche Prüfsummen-Datenbank für jeden Pfad, auf den es eine Übereinstimmung findet, sodass ein weit gefasstes Muster diesen Schutz in weitaus größerem Umfang deaktivieren kann, als beabsichtigt.

Im Mai 2026 machten Forscher auf eine Welle bösartiger Go-Module aufmerksam, die unter einem GitHub-Konto namens BufferZoneCorpveröffentlicht wurden. Der Diebstahl von Anmeldedaten war Teil der Payload, doch das Interessante war, worauf es bei mehreren dieser Go-Module ankam: die Build-Infrastruktur selbst. Sie manipulierten GOPROXY, schwächten die Prüfsummenüberprüfung ab, änderten die Datei „go.sum“ und platzierten gefälschte Go-Wrapper in den Workflow-Pfaden, sodass spätere CI-Schritte die Binärdatei des Angreifers anstelle der echten Toolchain ausführten. Das Go-Sicherheitsteam blockierte die identifizierten Module. Die Technik funktioniert nach wie vor überall dort, wo die Modulverknüpfung als Konfiguration und nicht als Sicherheitsgrenze behandelt wird.

Durch das Caching erhält diese Infrastruktur ein langes Gedächtnis. Ein Modul kann noch lange erreichbar bleiben, nachdem sich sein Quellcode geändert hat oder verschwunden ist, und eine frühere Sicherheitslücke in Go hat gezeigt, wie weit das geht – der öffentliche Go-Modul-Proxy stellte noch mehr als drei Jahre lang eine bösartige Version bereit, nachdem das entsprechende GitHub-Tag stillschweigend umgeschrieben worden war (mehr dazu weiter unten). Dieses Persistenzproblem ist ein wesentlicher Grund dafür, warum Teams einen internen Modul-Proxy einrichten und GOPROXY darauf verweisen.

Der Instinkt täuscht nicht. Die Reproduzierbarkeit der Builds verbessert sich, zwischengespeicherte Abhängigkeiten sind nicht mehr davon abhängig, dass der öffentliche Proxy erreichbar ist, und endlich gibt es einen zentralen Ort, an dem man sehen kann, von welchen Komponenten die Organisation abhängt.

Was daraus jedoch nicht folgt, ist die Schlussfolgerung hinsichtlich der Sicherheit. Ein Modul-Proxy liefert Bytes aus. Das Protokoll selbst sieht weder einen Schritt zur Inhaltsüberprüfung noch einen Mechanismus zur Durchsetzung von Richtlinien vor und trifft keine Entscheidung darüber, was in den Dateien enthalten ist, die es zurückgibt. Einen eigenen Proxy zu betreiben bedeutet, den Cache zu kontrollieren – das ist zwar nützlich, aber nicht dasselbe wie zu kontrollieren, was in den Cache gelangt.

Was ein Go-Modul-Proxy eigentlich macht

Das Modul-Proxy-Protokoll ist bewusst klein gehalten. Ein Proxy ist ein HTTP-Server, der pro Modulpfad eine Handvoll Endpunkte bereitstellt:

Das ist alles. Nichts auf dieser Liste enthält eine Signatur, ein Scan-Ergebnis, eine Sicherheitsbewertung oder irgendeine nachprüfbare Angabe zur Herkunft des Codes.

Hinweis: Da es sich bei dem Protokoll um einfache HTTP-GET-Anfragen über eine vorhersehbare Pfadstruktur handelt, gilt ein von NGINX bereitgestelltes Verzeichnis mit Dateien technisch gesehen als gültiger Go-Modul-Proxy. Das ist einer der Gründe, warum sich Proxys in der Go-Welt so schnell verbreitet haben, und einer der Gründe, warum so wenige von ihnen irgendetwas überprüfen – es sei denn, man integriert diese Überprüfung selbst.

Die Überprüfung in Go erfolgt auf der Client-Seite, nicht auf dem Proxy. Der Befehl „go“ vergleicht den Inhalt des heruntergeladenen Moduls mit dem Hashwert in „go.sum“. Ist dieser Hashwert noch nicht gespeichert, wird er in der Regel aus der Prüfsummen-Datenbank – einem unabhängigen, nur-zum-Anhängen-Protokoll – abgerufen, bevor er in „go.sum“ geschrieben wird. Nach der Speicherung vergleichen spätere Builds den Inhalt lediglich mit diesem gespeicherten Hashwert.

Die Sicherheitseigenschaften, die die meisten Teams ihrem Proxy zuschreiben, sind also in Wirklichkeit Eigenschaften von go.sum und GOSUMDB. Diese funktionieren genau gleich, egal ob Sie einen Proxy betreiben oder direkt auf proxy.golang.org aufrufen.

Das Komma und der Pipe-Zeichen bestimmen Ihr Fallback-Verhalten

GOPROXY nimmt eine Liste von Quellen entgegen, und das Trennzeichen zwischen ihnen bestimmt, was geschieht, wenn eine dieser Quellen ausfällt.

# Springt nur bei einem 404- oder 410-Fehler zum nächsten Eintrag weiter

GOPROXY=https://goproxy.internal.example.com,direct

# Springt bei JEDEM Fehler zum nächsten Eintrag weiter

GOPROXY=https://goproxy.internal.example.com|direct

Dieses Diagramm geht davon aus, dass „direct“ die nächste Quelle in der Liste ist, so wie es in den obigen Beispielen dargestellt ist. Für sich genommen bedeutet ein Pipe-Zeichen lediglich, dass die Ausführung an das Folgende weitergeleitet wird.

Ein Komma weist den Befehl „go“ an, die nächste Quelle erst dann zu versuchen, wenn die aktuelle Quelle eindeutig meldet, dass das Modul nicht vorhanden ist (Fehlercode 404 oder 410). Ein Pipe-Zeichen weist ihn an, die nächste Quelle bei jedem beliebigen Fehler zu versuchen, einschließlich Zeitüberschreitungen, TLS-Fehlern und 500-Fehlern.

Stellen Sie sich vor, was das mitten in einem Vorfall bedeutet. Ihr interner Proxy weist einen Fehler bei der Bereitstellung auf und gibt plötzlich 502-Fehler aus. Bei einer Konfiguration mit „Pipe“ gefolgt von „Direct“ beginnen alle Builds im gesamten Unternehmen stillschweigend, Module stattdessen aus dem öffentlichen Versionskontrollsystem abzurufen.

Profi-Tipp: Schauen Sie sich an, was in Ihrer CI tatsächlich eingestellt ist, und nicht, was laut Runbook eingestellt sein soll. GOFLAGS und GOPROXY werden oft von Basis-Images übernommen, und eine Pipe, die jemand vor zwei Jahren hinzugefügt hat, um eine instabile Bereitstellung zu ermöglichen, ist genau die Art von Änderung, die jede nachfolgende Überprüfung übersteht, weil die Builds weiterhin erfolgreich sind.

Auch das abschließende „direct“ in den meisten GOPROXY-Zeichenketten verdient eine eigene Betrachtung. Es weist die Toolchain an, auf die Versionskontrolle zurückzugreifen, wenn der Proxy keine Ergebnisse liefert, sodass ein Modulpfad, den Ihr Proxy noch nie gesehen hat, wie gewohnt direkt aus dem Upstream-Repository aufgelöst wird. Wenn der Sinn und Zweck der Einrichtung eines Proxys darin bestand, die einzige Quelle der Wahrheit zu sein, macht „direct“ dies stillschweigend zunichte.

„GOPROXY=off“ ist die strengste Option. Der Befehl „go“ lädt dann überhaupt keine Module herunter, sodass alles, was für einen Build benötigt wird, bereits im Modul-Cache vorhanden sein muss. Wenn Sie den abschließenden „direct“ weglassen, erhalten Sie eine strenge Quellcode-Grenze, ohne ganz so weit zu gehen.

Warum Selbsthosting allein nichts verifiziert

Athens ist eine zuverlässige Software. Sie erfüllt genau die Aufgaben, für die ein Modul-Proxy vorgesehen ist.

Was jedoch nicht enthalten ist, ist eine Aussage darüber, was sich im Inneren eines Moduls befindet. Es gibt keinen integrierten Malware-Scan, keine Überprüfung, ob das Archiv mit seinem Quell-Repo übereinstimmt, und keine sofort einsatzbereite Möglichkeit zu sagen: „Blockiere dieses Modul, es hat in Version 1.4.2 angefangen, etwas Neues zu tun.“ Die Standardfilterung arbeitet mit Modulpfaden und nicht mit dem, was der Code tatsächlich tut. Athens stellt jedoch einen Validierungs-Hook bereit, der bei jedem Modul-Download aufgerufen wird, sodass Betreiber ihn mit eigener Scan- oder Richtlinienlogik erweitern können; diese Überprüfung müssen Sie jedoch selbst entwerfen, ausführen und aufrechterhalten.

Diese Lücke ist von Bedeutung, da bösartiger Go-Code an bestimmten Stellen ausgeführt wird. Go verfügt nicht über einen Skript-Hook zur Installationszeit, wie es npm , was ein echter Pluspunkt ist. Aber bösartiger Code in einem Go-Modul wird dennoch später ausgeführt, nämlich wenn eine Anwendung oder ein Tool, das das Paket importiert, gestartet wird – in der Regel über eine init()-Funktion, die beim Programmstart aufgerufen wird.

Ein Proxy, der dieses Modul zwischenspeichert und bereitstellt, hat gemäß der Spezifikation nichts falsch gemacht. Er hat genau die Aufgabe erfüllt, für die er entwickelt wurde.

Die eigentliche Lücke besteht darin, ob das Archiv, das ein Proxy ausliefert, mit dem Quell-Repository übereinstimmt, auf das sein Modulpfad angeblich verweist. Das Protokoll schreibt nirgends vor, dass eine Modul-ZIP-Datei einem bestimmten Commit entsprechen muss, wodurch sie eher ein Artefakt als eine Bescheinigung darstellt. Das Neuaufbauen eines Moduls aus dem Quellcode und der Vergleich des Ergebnisses mit dem, was der Pfad ausgeliefert hat, ist eine andere Kontrollmaßnahme, die erfolgen muss, bevor das Artefakt in einen vertrauenswürdigen Speicher aufgenommen oder für einen Build bereitgestellt wird.

Fünf GOPROXY-Architekturen im Vergleich

Fünf Spielzüge decken fast alles ab, was die Mannschaften im Training üben. Der Unterschied zwischen ihnen liegt darin, welche Spieler bei jedem Spielzug einen Block setzen und wer für dessen Ausführung verantwortlich ist.

Der öffentliche Proxy mit direktem Fallback ist die Standardeinstellung, mit der die meisten Teams beginnen, und er ist besser als sein Ruf. proxy.golang.org verwaltet einen unveränderlichen Cache, sodass eine einmal bereitgestellte Version auch dann verfügbar und unverändert bleibt, wenn das Upstream-Repository gelöscht wird. Das ist eine echte Sicherheitseigenschaft, die beim Selbsthosting nicht automatisch gegeben ist.

Viele Teams entscheiden sich letztendlich für einen selbst gehosteten Proxy wie Athens, und ehrlich gesagt sorgt dieser eher für Verfügbarkeit und Transparenz als für Verifizierung.

Ein Repository-Manager-Proxy ermöglicht eine zentralisierte Zugriffskontrolle und kann – je nach Produkt und den von Ihnen lizenzierten Richtlinien-Add-ons – Komponenten anhand von Richtlinien überprüfen und diejenigen unter Quarantäne stellen, die diese nicht erfüllen. Was eine gewöhnliche Proxy-Lösung jedoch nach wie vor nicht gewährleisten kann, ist, dass ein Artefakt tatsächlich aus der Quelle neu erstellt wurde, auf die sein Pfad verweist, und dieser auch entspricht.

Eine geprüfte und neu kompilierte Registry stellt eine eigene Kategorie dar und ist keine Variante der ersten vier. Dabei wird jedes Modul aus dem Quellcode neu kompiliert und vor der Bereitstellung auf Malware geprüft; daher ist dies die einzige Zeile, bei der die Spalte „Prüfung“ mit „Ja“ beantwortet wird. Das ist das Modell SecureChain für Go basiert, wobei die Go-Unterstützung für das 4. Quartal 2026 geplant ist.

Woher der Missbrauch von Proxy-Caches stammt

Cache-bezogene Vorfälle, die die Infrastruktur von Go-Modulen betreffen, verlaufen in der Regel nach dem gleichen Muster, was ein Vorfall aus dem Frühjahr 2025 gut veranschaulicht. Im Februar jenes Jahres entdeckten Forscher ein Modul namens github.com/boltdb-go/bolt , das sich als BoltDB ausgab – ein weit verbreiteter eingebetteter Schlüssel-Wert-Speicher, der zum Zeitpunkt der Meldung des Vorfalls mehr als 8.000 abhängige Pakete hatte.

Der Angreifer hatte die schädliche Version bereits im November 2021 veröffentlicht und anschließend das GitHub-Tag so umgeschrieben, dass es auf einen sauberen Commit verwies, was bedeutete, dass jeder, der das Repository manuell überprüfte, nichts Verdächtiges bemerkte. Der Go-Modul-Proxy hatte die ursprüngliche schädliche Version bereits zwischengespeichert, und da dieser Cache so konzipiert ist, dass er unveränderlich ist, blieb die mit einer Hintertür versehene Kopie mehr als drei Jahre lang für jeden Client verfügbar, der diese Modulversion aufrief, bis Forscher sie schließlich als Typosquat.

Es handelte sich hierbei nicht um einen Prüfsummenfehler. „boltdb-go/bolt“ war ein eigenständiger, sich als echtes Modul ausgebender Pfad, sodass es keine vertrauenswürdige Prüfsumme für die echte BoltDB gab, mit der die gefälschte Version hätte übereinstimmen müssen. Die Integritätsprüfungen von Go haben die Bytes des Typosquats ohne Weiteres authentifiziert, da genau das die Aufgabe dieser Prüfungen ist. Die Hintertür war aufgrund der Namensgebung erfolgreich.

Diese Unterscheidung ist wichtig, da sie sich vom reinen Vertrauen bei der ersten Nutzung unterscheidet. Bei öffentlichen Modulen überprüft der Client normalerweise die Prüfsummen-Datenbank – ein unabhängig authentifiziertes Protokoll –, sobald er zum ersten Mal einen Hash für eine Version benötigt. So kann ein Proxy den vertrauenswürdigen Wert für eine bereits erfasste Version nicht einseitig ändern. Ein selbst gehosteter Proxy entscheidet zwar weiterhin, welches Artefakt der Client zuerst sieht, doch mit GOSUMDB ist es die Prüfsummen-Datenbank und nicht der Proxy, die darüber entscheidet, ob dieses Artefakt akzeptiert wird.

All das prüft jedoch nicht, ob ein Modul überhaupt vertrauenswürdig ist – und genau diese Lücke nutzt ein Typosquat aus. Der öffentliche Teil wird zudem bei allem außer Kraft gesetzt, was mit GOPRIVATE übereinstimmt, sowie in jeder Umgebung, in der GOSUMDB auf „off“ gesetzt ist.

Was GOPRIVATE stillschweigend deaktiviert

GOPRIVATE gibt es aus gutem Grund. Private Module sollten nicht über einen öffentlichen Proxy angefordert werden, und ihre Pfade sollten auch nicht an eine öffentliche Prüfsummen-Datenbank gesendet werden, da der Modulpfad selbst Informationen darüber preisgeben kann, was Sie gerade erstellen.

Es handelt sich dabei auch um eine Komfortvariable, und genau dieser Nebeneffekt führt dazu, dass die Dinge schiefgehen. GOPRIVATE liefert den Standardwert sowohl für GONOPROXY als auch für GONOSUMDB, gemäß Go-Modulreferenz, was bedeutet, dass jeder Pfad, auf den es passt, gleichzeitig vom Proxy und aus der öffentlichen Prüfsummen-Datenbank ausgeschlossen wird, es sei denn, eine dieser beiden Variablen wird separat gesetzt.

Und genau hier liegt in der Praxis das Problem.

GOPRIVATE=github.com/yourcompany/*

Wenn die Suche eng genug gefasst ist, wird genau die Organisation gefunden, die Sie gesucht haben.

GOPRIVATE=*.example.com,github.com/*

Dieses zweite Muster schließt jedes auf GitHub gehostete Modul aus der öffentlichen Prüfsummen-Datenbank aus, die einen enormen Anteil dessen abdeckt, was die meisten Go-Builds beziehen. Muster können sich auf diese Weise leicht ausweiten: Ein Fehler bei der Auflösung muss behoben werden, und eine Lockerung der Übereinstimmungsbedingungen ist die Änderung, die den Build sofort zum Erfolg führt.

Überprüfen Sie, welche Einstellungen in Ihren Umgebungen tatsächlich vorgenommen wurden:

go env GOPROXY GOSUMDB GOPRIVATE GONOPROXY GONOSUMDB GOFLAGS

Führen Sie das auf einem CI-Runner aus, nicht nur auf Ihrem Laptop. Es kann zu Abweichungen kommen, da CI Variablen aus Basis-Images und der Runner-Konfiguration übernimmt.

Legen Sie diese bewusst fest. Konfigurieren Sie GONOPROXY und GONOSUMDB direkt, wenn sich Ihr Routing und Ihre Prüfsummenrichtlinie unterscheiden müssen – was häufiger vorkommt, als Teams erwarten. Wenn ein vertrauenswürdiger interner Proxy sowohl öffentliche als auch private Module bedient, sorgt GONOPROXY=none dafür, dass der gesamte Datenverkehr über diesen Proxy läuft, während GONOSUMDB nur die tatsächlich privaten Pfade abdeckt. Was Sie vermeiden sollten, ist das Gegenteil: private Pfade in der öffentlichen Datenbank abfragen zu lassen, was entweder den Build unterbricht oder den Pfad an einen öffentlichen Dienst preisgibt.

Auswahl einer Architektur

Die Entscheidung hängt davon ab, welches Problem Sie tatsächlich lösen wollen, und wenn Sie sich darüber im Klaren sind, verkürzt sich die Dauer des gesamten Projekts erheblich.

Wenn die treibenden Faktoren Verfügbarkeit und Reproduzierbarkeit der Builds sind, sollten Sie einen selbst gehosteten Proxy oder einen Repository-Manager einsetzen, ein Komma anstelle einer Pipe verwenden und aufhören, dies als Sicherheitsmaßnahme zu bezeichnen. Es handelt sich um eine gute Infrastruktur, die genau die Aufgabe erfüllt, für die sie entwickelt wurde. Wenn der treibende Faktor der Einblick in die Abhängigkeiten des Unternehmens ist, reicht fast jeder Proxy aus, um dieses Ziel zu erreichen, und Repository-Manager bieten eine bessere Berichterstattung bei geringerem betrieblichen Aufwand.

Wenn der Treiber die Durchsetzung von Richtlinien darüber ist, welche Module zugelassen sind, bildet ein Repository-Manager mit Pfadregeln die Basis, und die eigentliche Durchsetzung erfolgt über dessen Richtlinien- oder Firewall-Erweiterungen. Athens lässt sich über seinen Validierungs-Hook in diese Richtung lenken, aber die Logik, die Feinabstimmung und die Benachrichtigungen liegen in Ihrer Verantwortung.

Wenn der Treiber überprüfen möchte, ob der Inhalt eines Moduls vertrauenswürdig ist, liefert das Proxy-Protokoll allein keine Antwort darauf, da es nie mit einem Verifizierungsschritt konzipiert wurde. Diese Kontrolle muss entweder auf der Ebene des Proxys stattfinden oder von einem System kommen, das Artefakte anhand der Quelle validiert, bevor sie bereitgestellt werden.

Und wenn Go in Ihrem Stack neben npm, PyPI, Maven oder crates.io zum Einsatz kommt, legen Sie die Architektur einmalig für alle diese Plattformen fest. Fünf Proxys pro Ökosystem, die von fünf verschiedenen Teams betrieben werden, sind genau der Grund, warum Lücken in der Abdeckung entstehen. PolinRider ist ein gutes Beispiel dafür, warum das so ist: Die unter diesem Namen nachverfolgte, mit Nordkorea in Verbindung stehende Kampagne hat schädliche Pakete über npm, Packagist, Go-Module und Chrome-Erweiterungen veröffentlicht, und sie war immer noch aktiv, als Forscher im Juli 2026 darüber berichteten. Der größere „Contagious Interview“-Cluster, zu dem sie gehört, wurde mit mehr als 1.700 schädliche Pakete über npm, PyPI, Go und Rust in Verbindung gebracht. Ein Problem auf Stack-Ebene erfordert eine Lösung auf Stack-Ebene, nicht fünf voneinander getrennte Caches.

Ein Proxy ist der richtige Ort, um Probleme hinsichtlich Verfügbarkeit, Latenz und Reproduzierbarkeit zu lösen. Er eignet sich jedoch kaum, um Vertrauensfragen zu klären. Indem man diese beiden Ziele voneinander trennt, bleibt die Architektur einfach und es kann ein funktionsfähiger Proxy bereitgestellt werden. Werden sie hingegen miteinander vermischt, verwandelt sich ein unkompliziertes Caching-Projekt in ein weitaus umfangreicheres Vorhaben im Bereich der Richtlinien- und Sicherheitsentwicklung – mit dem realen Risiko, dass am Ende eine komplexe Richtlinienebene entsteht, die an eine im Grunde genommen reine Caching-Komponente angehängt wird.

Wo TuxCare SecureChain zum Einsatz kommt

Es gibt außerdem ein Problem, das kein Proxy löst: Module, die niemand mehr pflegt. Ein Cache bedient ein inaktives Modul genauso zuverlässig wie ein aktiv gepflegtes, und ein ungepatchtes Modul mit einer bekannten CVE und ohne Upstream-Korrektur ist kein Problem, das eine Cache-Architektur löst. Das Backportieren einer Korrektur auf Code, von dem sich der Betreuer zurückgezogen hat, ist eine eigene Disziplin, die auf Regressionstests und Verhaltenskompatibilität basiert – was in der Regel der Grund dafür ist, dass dies außerhalb des Zuständigkeitsbereichs eines Plattformteams liegt.

Wenn in Ihrer Architektur die Verifikation fehlt, ist das die Lücke SecureChain wurde entwickelt, um diese Lücke über die Ökosysteme hinweg zu schließen, die normalerweise im selben Stack angesiedelt sind. npm ist ab heute verfügbar, Maven und PyPI folgen im August 2026, und Go sowie Rust/crates.iosowie Packagist/PHP im vierten Quartal 2026. In jedem dieser Fälle erstellt SecureChain Pakete aus dem Quellcode neu, überprüft sie beim Abruf, bevor sie in den Build gelangen, und patcht bekannte Schwachstellen auch dann weiter, wenn der Upstream eines Pakets nicht mehr aktiv ist. Sie fragen sich, wie sich das in Ihre eigene GOPROXY-Konfiguration oder den Rest Ihres Stacks einfügt? Stellen Sie uns eine Frage und das Team wird Ihnen alles erklären.

FAQ

Was ist ein Go-Modul-Proxy?

Ein HTTP-Server, der das Go-Modul-Proxy-Protokoll implementiert. Er stellt Versionslisten, Metadaten, „go.mod“-Dateien und Quellcode-Archive für Modulpfade bereit. Er speichert Inhalte zwischen und leitet sie weiter, wobei das Protokoll selbst keine Überprüfung der zurückgegebenen Inhalte vorsieht.

Macht der Betrieb eines eigenen Go-Modul-Proxys die Builds sicherer?

Es verbessert die Verfügbarkeit, Reproduzierbarkeit und Sichtbarkeit – alles nützliche Aspekte. Das Proxy-Protokoll selbst enthält keinen eigenen Verifizierungsschritt. Die Authentifizierung der Inhalte erfolgt clientseitig: Der Befehl „go“ gleicht Downloads mit go.sum ab und, bei öffentlichen Modulen, mit der Prüfsummen-Datenbank, wenn noch kein Hash gespeichert ist. Das funktioniert unabhängig davon, ob ein Proxy läuft oder nicht, es sei denn, GOSUMDB ist deaktiviert oder der Pfad wurde über GOPRIVATE oder GONOSUMDB aus der öffentlichen Datenbank ausgeschlossen.

Was ist der Unterschied zwischen einem Komma und einem Pipe-Zeichen in GOPROXY?

Ein Komma bewirkt, dass der „go“-Befehl nur bei einem 404- oder 410-Fehler an die nächste Quelle weitergeleitet wird; jeder andere Proxy-Fehler stoppt die Auflösung. Ein Pipe-Zeichen bewirkt, dass der Befehl bei jedem beliebigen Fehler weitergeleitet wird, was bedeutet, dass ein Proxy-Ausfall Builds unbemerkt ins öffentliche Internet senden kann, anstatt einfach nur zu scheitern.

Deaktiviert GOPRIVATE die Prüfsummenüberprüfung?

Standardmäßig wird die Abfrage der öffentlichen Prüfsummen-Datenbank für übereinstimmende Pfade übersprungen, da GOPRIVATE Daten an GONOSUMDB übermittelt. Ein bereits vorhandener Eintrag in go.sum kann eine spätere Inhaltsänderung dennoch erfassen.

Reicht Athens für einen privaten Go-Modul-Proxy aus?

Was Verfügbarkeit, Caching und die interne Modulverteilung angeht, ja. Die Standardfilterung erfolgt anhand der Modulpfade und nicht anhand des Inhalts, sodass das System standardmäßig nicht anzeigt, ob ein Modul bösartig ist oder ob das bereitgestellte Archiv mit dem Quell-Repository übereinstimmt. Der Validierungs-Hook lässt sich um eine solche Logik erweitern, doch diesen Teil müssen Sie selbst entwerfen und betreiben.

Wie kann ich überprüfen, welchen Komponenten meine Go-Builds tatsächlich vertrauen?

Führen Sie den Befehl „go env GOPROXY GOSUMDB GOPRIVATE GONOPROXY GONOSUMDB GOFLAGS“ auf einem CI-Runner aus. Die von Basis-Images und Runner-Einstellungen übernommenen Konfigurationen weichen häufig von lokalen Entwicklungsumgebungen ab – und auch von den im Runbook festgelegten Vorgaben.

Zusammenfassung

Artikel Name

Proxy-Optionen des Go-Moduls und was GOPROXY tatsächlich überprüft

Beschreibung

Ein Go-Modul-Proxy speichert Daten zwischen und leitet sie weiter, wobei das Protokoll keinerlei Überprüfung des Modulinhaltes vornimmt. Es kommt darauf an, was GOPROXY, GOPRIVATE und die Prüfsummen-Datenbank entscheiden.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers