dependabot core
v0.289.0
Willkommen im öffentlichen Zuhause von Dependabot.
Dependabot-Core ist die Bibliothek im Herzen der Dependabot-Sicherheits-/Versionsaktualisierungen.
Verwenden Sie es, um automatisierte Pull-Anfragen zu generieren, die Abhängigkeiten für Projekte aktualisieren, die in Ruby, JavaScript, Python, PHP, Dart, Elixir, Elm, Go, Rust, Java und .NET geschrieben sind. Es kann auch Git-Submodule, Docker-Dateien und Terraform-Dateien aktualisieren. Zu den Funktionen gehören:
Die meisten Menschen sind mit dem Dependabot-Dienst vertraut, der auf GitHub.com und GitHub Enterprise läuft. Um dies zu aktivieren, müssen Sie lediglich eine dependabot.yml Konfigurationsdatei in das .github Verzeichnis Ihres Repositorys einchecken.
Wenn Sie jedoch eine benutzerdefinierte Version von Dependabot oder auf einer anderen Plattform ausführen möchten, stehen Sie nicht im Regen. Dieses Repo bietet die notwendige Logik zum Hosten Ihres eigenen eigenständigen Dependabot. Es unterstützt derzeit das Öffnen von Pull-Requests für Repositorys, die auf GitHub, Github Enterprise, Azure DevOps, GitLab, BitBucket und AWS CodeCommit gehostet werden.
Dependabot-Core ist eine Bibliothek, daher benötigen Sie eine Art Einstiegspunktskript. Hier sind ein paar Beispiele, die Ihnen den Einstieg erleichtern sollen.
Hinweis: Wenn Sie Dependabot zu Entwicklungs-/Debugzwecken lokal ausführen möchten, lesen Sie das Entwicklungshandbuch.
Das Dependabot-Script-Repository bietet eine Sammlung von Beispielskripten zum Konfigurieren der Dependabot-Core-Bibliothek. Es ist als Ausgangspunkt für fortgeschrittene Benutzer gedacht, um eine selbst gehostete Version von Dependabot in ihren eigenen Projekten auszuführen.
Hinweis: Wir haben kürzlich das monolithische Docker-Image, das in der Dependabot Core-Bibliothek verwendet wird, in ein Image pro Ökosystem umgestaltet. Leider sind die Dependabot-Skripte dadurch kaputt gegangen, und wir hatten noch keine Zeit, sie zu aktualisieren. Wir sind uns des Problems bewusst und hoffen, bald eine Lösung anbieten zu können.
Die Dependabot-CLI ist ein neueres Tool, das möglicherweise dependabot-script für eigenständige Anwendungsfälle ersetzt. Es werden zwar Abhängigkeitsunterschiede erstellt, es fehlt jedoch derzeit die Logik, um diese Unterschiede in tatsächliche PRs umzuwandeln. Dennoch kann es für fortgeschrittene Benutzer nützlich sein, die nach Beispielen für das Hacken von Dependabot suchen.
Wenn Sie in einer Umgebung wie GitHub, in der Dependabot in einem Container ausgeführt wird, Ihren Build- oder Installationsprozess abhängig davon ändern möchten, ob Dependabot prüft, können Sie dies anhand der Existenz der Umgebungsvariablen DEPENDABOT ermitteln.
Möchten Sie uns Feedback zu Dependabot geben oder dazu beitragen? Das ist großartig – vielen Dank!
Den meisten Fehlerberichten sollte ein Link zu einem öffentlichen Repository beigefügt sein, das das Problem reproduziert. Fehlerberichte, die nicht mit dem CLI-Tool oder einem Probelaufskript in einem öffentlichen Repo reproduziert werden können, werden möglicherweise mit der Meldung „Kann nicht reproduziert werden“ geschlossen.
Unser Issue-Tracker ist ziemlich aktiv und daher besteht eine gute Chance, dass jemand bereits dasselbe Problem gemeldet hat. Wenn ja, stimmen Sie diesem Problem bitte positiv zu, da wir ? Reaktionen auf Probleme als ein Signal, um die Auswirkungen einer Funktionsanfrage oder eines Fehlers abzuschätzen.
Bitte hinterlassen Sie jedoch keine Kommentare, die nichts Neues zur Diskussion beitragen. Einzelheiten finden Sie unter https://github.com/golang/go/wiki/NoPlusOne. Dies ist Open Source. Wenn Sie etwas sehen, das Sie beheben möchten, beraten wir Sie gerne, indem wir eine Pull-Anfrage stellen, um das Problem zu beheben.
Der Issue-Tracker ist ausschließlich für Probleme im Zusammenhang mit der Aktualisierungslogik von Dependabot gedacht. Probleme zu Sicherheitswarnungen oder Dependency Graph sollten stattdessen als Diskussion zur Codesicherheit eingereicht werden.
Eine gute Faustregel lautet: Wenn Sie Fragen zum Diff in einer PR haben, gehören diese hierher.
Wenn Sie glauben, eine Sicherheitslücke in Dependabot gefunden zu haben, lesen Sie bitte unsere Sicherheitsrichtlinie für Einzelheiten zur Offenlegung dieser Schwachstelle im GitHub Bug Bounty-Programm, damit wir daran arbeiten können, das Problem zu beheben, bevor es öffentlich bekannt gegeben wird.
Möchten Sie zu Dependabot beitragen? Das ist großartig – vielen Dank!
Beitrags-Workflow:
Weitere Informationen finden Sie in den CONTRIBUTING-Richtlinien.
Wenn Sie daran interessiert sind, Unterstützung für ein neues Ökosystem beizutragen, lesen Sie bitte die Beitragsrichtlinien für weitere Informationen.
Der erste Schritt zum Debuggen eines Problems oder zum Schreiben einer neuen Funktion besteht darin, eine Entwicklungsumgebung in Betrieb zu nehmen. Wir stellen eine benutzerdefinierte Docker-basierte Entwickler-Shell bereit, die alle erforderlichen Abhängigkeiten integriert. In den meisten Fällen ist dies die beste Art, mit dem Projekt zu arbeiten.
Die Entwickler-Shell verwendet Volume-Mounts, um Ihre lokalen Änderungen in den Quellcode von Dependabot zu integrieren. Auf diese Weise können Sie lokal mit Ihrem bevorzugten Editor bearbeiten und die Änderungen werden sofort im Docker-Container widergespiegelt, um Probeläufe oder Tests durchzuführen. Hinweis: Beachten Sie den Vorbehalt zum Bearbeiten der Hilfsskripts des nativen Paketmanagers.
Das Skript zum Starten der Entwickler-Shell erstellt die Docker-Images von Grund auf, wenn es sie lokal nicht finden kann. Dies kann eine Weile dauern.
Überspringen Sie die Wartezeit, indem Sie das vorgefertigte Image für das Ökosystem abrufen, an dem Sie arbeiten möchten. Der Bildname verwendet den Namen des YAML-Ökosystems, um das Ökosystem anzugeben. Für Go-Module lautet der YAML-Name beispielsweise gomod :
$ docker pull ghcr.io/dependabot/dependabot-updater-gomodHinweis: Vorgefertigte Images sind derzeit nur für die AMD64-/Intel-Architektur verfügbar. Sie werden auf ARM ausgeführt, jedoch zwei- bis dreimal langsamer, als wenn Sie manuell ARM-spezifische Images erstellen.
Führen Sie als Nächstes die Entwickler-Shell aus und geben Sie das gewünschte Ökosystem mithilfe des Verzeichnisnamens der obersten Ebene des Ökosystems in diesem Projekt an. Für Go-Module heißt das Verzeichnis der obersten Ebene beispielsweise go_modules :
$ bin/docker-dev-shell go_modules
= > running docker development shell
[dependabot-core-dev] ~ $ cd go_modules && rspec spec # to run tests for a particular packageNormalerweise ist der Quickstart alles, was Sie brauchen, aber gelegentlich müssen Sie die zugrunde liegenden Bilder neu erstellen.
Während wir beispielsweise noch keine ARM-spezifischen Images veröffentlichen, empfehlen wir, wenn Sie auf einer ARM-basierten Plattform arbeiten , die Images manuell zu erstellen, da die resultierenden Container viel schneller laufen.
Die Entwickler-Shell wird in einem Docker-Image von Dependabot Development ausgeführt, das auf einem Ökosystem-Image aufbaut.
Flussdiagramm LR
A["docker-dev-shell script"] --> B("Dependabot Development Docker Image")
B --> C("Dependabot Updater Ecosystem Docker Image (ökosystemspezifisch)")
C -> D („Dependabot Updater Core Docker-Image“)
Änderungen an den Docker-Dateien für eines dieser Images erfordern die lokale Erstellung eines oder mehrerer Images, damit sie in der Entwicklungs-Shell berücksichtigt werden.
Der einfache, aber langsame Weg besteht darin, alle vorhandenen Bilder zu löschen und dann bin/docker-dev-shell auszuführen, wodurch fehlende Bilder automatisch erstellt werden.
Der schnellere Weg besteht darin, alle vorgefertigten Images abzurufen, die von dem Image abhängig sind, das Sie tatsächlich erstellen müssen. Um ein bestimmtes (neu) zu erstellen:
Das Updater-Kernbild:
$ docker pull ghcr.io/dependabot/dependabot-updater-core # OR
$ docker build -f Dockerfile.updater-core . # recommended on ARMDas Bild des Updater-Ökosystems:
$ docker pull ghcr.io/dependabot/dependabot-updater-gomod # OR
$ script/build go_modules # recommended on ARM Der Entwicklungscontainer mit dem Flag --rebuild :
$ bin/docker-dev-shell go_modules --rebuildMehrere Dependabot-Pakete nutzen „native Helfer“, kleine ausführbare Dateien in ihrer Hostsprache.
Änderungen an diesen Dateien werden nicht automatisch im Entwicklungscontainer widergespiegelt.
Nachdem Sie Änderungen an den Hilfsdateien vorgenommen haben, führen Sie das entsprechende Build-Skript aus, um die installierte Version wie folgt mit Ihren Änderungen zu aktualisieren:
$ bin/docker-dev-shell bundler
= > running docker development shell
$ bundler/helpers/v2/build
$ bin/dry-run.rb bundler dependabot/demo --dir= " /ruby "Informationen zum Anzeigen von Protokollen und Standardausgaben der nativen Paketmanager-Helfer finden Sie unter Debuggen nativer Helfer.
Der erste Schritt zum Debuggen besteht darin, die Entwicklungsumgebung zum Laufen zu bringen.
Innerhalb der Entwicklungsumgebung haben Sie zwei Möglichkeiten, einen Abhängigkeitsaktualisierungsjob zu simulieren: Sie können das neu entwickelte CLI-Tool oder das ursprüngliche Dry-Run-Skript verwenden.
Die Dependabot-CLI ist ein neu entwickeltes Tool, das den GitHub Credentials Proxy integriert, um realistischer zu simulieren, was innerhalb des Dependabot-at-GitHub-Dienstes bei der Kommunikation mit privaten Registern geschieht.
Es verfügt über eine spezielle Debugging-Anleitung, einschließlich Unterstützung für das Einfügen in den Ruby-Debugger.
Hinweis: Bevor Sie das Trockenlaufskript ausführen, müssen Sie die Entwicklungsumgebung zum Laufen bringen.
Sie können das Skript bin/dry-run.rb verwenden, um einen Abhängigkeitsaktualisierungsauftrag zu simulieren und den Diff, der generiert werden würde, auf dem Terminal auszugeben. Es benötigt zwei Positionsargumente: den Paketmanager und den GitHub-Repo-Namen (einschließlich des Kontos):
$ bin/docker-dev-shell go_modules
= > running docker development shell
$ bin/dry-run.rb go_modules rsc/quote
= > fetching dependency files
= > parsing dependency files
= > updating 2 dependencies
...Das Dry-Run-Skript unterstützt viele weitere Optionen, die alle oben im Quellcode des Skripts dokumentiert sind. Zum Beispiel:
LOCAL_GITHUB_ACCESS_TOKEN="fake-GitHub-PAT" ermöglicht die Angabe eines GitHub Personal Access Token (PAT), um eine Ratenbegrenzung zu vermeiden.--dir="path/to/subdir/containing/manifest ist erforderlich, wenn sich die Manifestdatei in einem Unterverzeichnis befindet.--dep="dep-name-that-I-want-to-test" ermöglicht die Angabe einer einzelnen Dep, die versucht zu aktualisieren, und alle anderen werden ignoriert.--cache=files ermöglicht das lokale Zwischenspeichern von Remote-Dep-Dateien für schnellere Wiederholungen beim Testen lokaler Logikänderungen.--updater-options=feature_flag_name ermöglicht die Übergabe von Feature-Flags.Hier ist ein Beispiel dafür, wie man all dies aneinanderreiht
LOCAL_GITHUB_ACCESS_TOKEN=github_pat_123_fake_string
bin/dry-run.rb docker jeffwidman/secrets-store-driver
--dir " /manifest_staging/charts/secrets-store-provider "
--cache=files
--dep= " secrets-store "
--updater-options=kubernetes_updates Sie können eine debugger Anweisung an einer beliebigen Stelle im Ruby-Code hinzufügen, zum Beispiel:
def latest_resolvable_version
debugger
latest_version_finder . latest_version
endWenn Sie den Job ausführen, wird der Ruby-Debugger geöffnet. Es sollte ungefähr so aussehen:
[ 11 , 20 ] in ~/ go_modules / lib / dependabot / go_modules / update_checker . rb
11 | module GoModules
12 | class UpdateChecker < Dependabot :: UpdateCheckers :: Base
13 | require_relative "update_checker/latest_version_finder"
14 |
15 | def latest_resolvable_version
=> 16 | debugger
17 | latest_version_finder . latest_version
18 | end
19 |
20 | # This is currently used to short-circuit latest_resolvable_version,
=> #0 Dependabot::GoModules::UpdateChecker#latest_resolvable_version at ~/go_modules/lib/dependabot/go_modules/update_checker.rb:16
#1 Dependabot::GoModules::UpdateChecker#latest_version at ~/go_modules/lib/dependabot/go_modules/update_checker.rb:24
# and 9 frames (use `bt' command for all frames)
( rdbg ) An dieser Eingabeaufforderung können Sie Debugger-Befehle ausführen, um zu navigieren, oder Methoden und Variablen eingeben, um zu sehen, was sie enthalten. Versuchen Sie, dependency einzugeben, um zu sehen, an welcher Abhängigkeit Dependabot gerade arbeitet.
Hinweis Im Debugger werden am Quellcode vorgenommene Änderungen nicht übernommen. Sie müssen Ihre Debugging-Sitzung beenden und neu starten.
Wenn Sie ein Problem debuggen, müssen Sie häufig einen Blick in diese Skripts werfen, die in einem separaten Prozess ausgeführt werden.
Drucken Sie alle Protokollanweisungen von nativen Hilfsprogrammen mit DEBUG_HELPERS=true aus:
DEBUG_HELPERS=true bin/dry-run.rb bundler dependabot/demo --dir= " /ruby " Unterbrechen Sie die Ausführung, um eine einzelne native Hilfsfunktion mit DEBUG_FUNCTION=<function name> zu debuggen. Die Funktion wird einem nativen Hilfsfunktionsnamen zugeordnet, beispielsweise einer der Funktionen in bundler/helpers/v2/lib/functions.rb .
Wenn diese Funktion ausgeführt wird, wird ein debugger eingefügt, der die Ausführung des Skripts bin/dry-run.rb anhält. Dadurch bleibt das aktuelle Updates tmp Verzeichnis erhalten, sodass Sie mit cd in das Verzeichnis wechseln und die native Hilfsfunktion direkt ausführen können:
DEBUG_FUNCTION=parsed_gemfile bin/dry-run.rb bundler dependabot/demo --dir= " /ruby "
= > fetching dependency files
= > dumping fetched dependency files: ./dry-run/dependabot/demo/ruby
= > parsing dependency files
$ cd /home/dependabot/dependabot-core/tmp/dependabot_TEMP/ruby && echo " { " function " : " parsed_gemfile " , " args " :{ " gemfile_name " : " Gemfile " , " lockfile_name " : " Gemfile.lock " , " dir " : " /home/dependabot/dependabot-core/tmp/dependabot_TEMP/ruby " }} " | BUNDLER_VERSION=1.17.3 BUNDLE_GEMFILE=/opt/bundler/v1/Gemfile GEM_HOME=/opt/bundler/v1/.bundle bundle exec ruby /opt/bundler/v1/run.rb Kopieren Sie den Befehl cd... und führen Sie ihn aus:
cd /home/dependabot/dependabot-core/tmp/dependabot_TEMP/ruby && echo " { " function " : " parsed_gemfile " , " args " :{ " gemfile_name " : " Gemfile " , " lockfile_name " : " Gemfile.lock " , " dir " : " /home/dependabot/dependabot-core/tmp/dependabot_TEMP/ruby " }} " | BUNDLER_VERSION=1.17.3 BUNDLE_GEMFILE=/opt/bundler/v1/Gemfile GEM_HOME=/opt/bundler/v1/.bundle bundle exec ruby /opt/bundler/v1/run.rb Dies sollte die Ausgabe der Funktion parsed_gemfile abmelden:
{ "result" : [ { "name" : "business" , "requirement" : "~> 1.0.0" , "groups" : [ "default" ] , "source" : null , "type" : "runtime" } , { "name" : "uk_phone_numbers" , "requirement" : "~> 0.1.0" , "groups" : [ "default" ] , "source" : null , "type" : "runtime" } ] }Beachten Sie, dass im Gegensatz zu Änderungen an der Ruby-Quelle Änderungen am Quellcode der nativen Hilfsprogramme auf Ihrem Hostcomputer nicht mit dem Entwicklungscontainer synchronisiert werden. Sie haben also zwei Möglichkeiten, den nativen Helfer zu bearbeiten:
vi /opt/bundler/v1/lib/functions/file_parser.rb . Und führen Sie dann den Befehl cd... erneut aus. Dies ist die schnellste Möglichkeit zum Debuggen, aber Änderungen werden nicht außerhalb des Containers gespeichert. Die meisten Ökosysteme in Dependabot-Core unterstützen ignore Bedingungen, die es einem Benutzer ermöglichen, Abhängigkeitsnamen oder -versionen anzugeben, die von Upgrades ausgeschlossen werden sollen. Die Dokumente für den Dependabot-Dienst auf GitHub beschreiben die Funktion ausführlicher.
Die Dependabot-CLI unterstützt die Übergabe von Ignorierbedingungen als Teil der Jobdefinition. Siehe das Beispiel.
Das Trockenlaufskript unterstützt die Übergabe einer oder mehrerer Ignorierbedingungen über die Umgebungsvariable IGNORE_CONDITIONS :
IGNORE_CONDITIONS= ' [{"dependency-name":"*","update-types": ["version-update:semver-major"]}] '
bin/dry-run.rb docker test_org/test-dependabot `Viele der Ökosysteme in Dependabot-Core unterstützen Sicherheitsupdates. Hierbei handelt es sich um eine spezielle Form der Versionsaktualisierung, bei der ein Abhängigkeitsname und ein Bereich anfälliger Versionen übergeben werden. Dependabot-Core versucht, jede Instanz dieser Abhängigkeit auf die minimale nicht anfällige Version zu aktualisieren. Dies steht im Gegensatz zu einem normalen Versionsupdate, bei dem versucht wird, auf die neueste Version zu aktualisieren.
Die Umgebungsvariable SECURITY_ADVISORIES ermöglicht die Übergabe einer oder mehrerer Sicherheitswarnungsbenachrichtigungen an das Probelaufskript, um ein Sicherheitsupdate zu simulieren:
SECURITY_ADVISORIES= ' [{"dependency-name":"buffer","patched-versions":[],"unaffected-versions":[],"affected-versions":["<= 2.0.0"]}] '
bin/dry-run.rb pub dart-lang/pub-dev --dir " /app " --cache=files --dep= " buffer " Es gibt integrierte Unterstützung für die Nutzung der Visual Studio Code-Fähigkeit zum Debuggen in einem Docker-Container. Drücken Sie nach der Installation der empfohlenen Dev Containers Erweiterung einfach Ctrl+Shift+P ( ⇧⌘P unter macOS) und wählen Sie Dev Containers: Reopen in Container aus. Sie können auf das Dropdown-Menü auch zugreifen, indem Sie auf die grüne Schaltfläche in der unteren linken Ecke des Editors klicken. Wenn das Entwicklungs-Docker-Image nicht auf Ihrem Computer vorhanden ist, wird es automatisch erstellt. Sobald dies abgeschlossen ist, starten Sie die Debug Dry Run Konfiguration (F5) und Sie werden aufgefordert, einen Paketmanager und ein Repository auszuwählen, für die Sie einen Dry-Run durchführen möchten. Fühlen Sie sich frei, Haltepunkte im Code zu platzieren.
Es gibt auch Unterstützung für das Debuggen einzelner Testläufe durch Ausführen der Debug Tests -Konfiguration (F5) Sie werden dann aufgefordert, ein Ökosystem auszuwählen und einen RSpec-Pfad anzugeben.
Clone Repository ... Befehlen der Remote Containers-Erweiterung fehlen derzeit einige Funktionen und werden daher nicht unterstützt. Sie müssen das Repository manuell klonen und den Befehl Reopen in Container oder Open Folder in Container... verwenden.
Sobald Sie die Entwicklungsumgebung für ein bestimmtes Ökosystem in Betrieb genommen haben, führen Sie die Tests für dieses Ökosystem durch, indem Sie rspec spec im Ordner dieses Ökosystems ausführen, z
$ cd go_modules
$ rspec specSie können die Tests auch auf die Datei beschränken, an der Sie gerade arbeiten, oder nur auf Tests, die zuvor fehlgeschlagen sind, zum Beispiel:
$ rspec spec/dependabot/file_updaters/elixir --only-failures Der Stil wird durch RuboCop erzwungen. Um nach Stilverstößen zu suchen, führen Sie einfach rubocop in jedem der Pakete aus, z
$ cd go_modules
$ rubocop Sie können einen Probelauf profilieren, indem Sie beim Ausführen das Flag --profile übergeben oder einen rspec -Test mit :profile kennzeichnen. Dadurch wird eine Datei stackprof-<datetime>.dump im Ordner tmp/ generiert. Sie können daraus einen Flamegraph erstellen, indem Sie Folgendes ausführen:
stackprof --d3-flamegraph tmp/stackprof- < data or spec name > .dump > tmp/flamegraph.htmlDependabot-Core ist eine Sammlung von Ruby-Paketen (Gems), die die Logik zum Aktualisieren von Abhängigkeiten in mehreren Sprachen enthalten.
dependabot-common Das common Paket enthält alle allgemeinen/gemeinsamen Funktionen. Hier befindet sich beispielsweise der Code zum Erstellen von Pull-Requests für die verschiedenen unterstützten Plattformen sowie der Großteil der Logik zur Handhabung von Git-Abhängigkeiten (da die meisten Sprachen Git-Abhängigkeiten auf die eine oder andere Weise unterstützen). Es gibt auch Basisklassen, die für jedes der Hauptanliegen definiert sind, die zur Implementierung der Unterstützung für einen Sprach- oder Paketmanager erforderlich sind.
dependabot-{package-manager}Für jeden Paketmanager oder jede Sprache, die Dependabot unterstützt, gibt es ein Juwel. Jeder dieser Edelsteine implementiert mindestens die folgenden Klassen:
| Service | Beschreibung |
|---|---|
FileFetcher | Ruft die relevanten Abhängigkeitsdateien für ein Projekt ab (z. B. Gemfile und Gemfile.lock ). Weitere Informationen finden Sie in der README-Datei. |
FileParser | Analysiert eine Abhängigkeitsdatei und extrahiert eine Liste von Abhängigkeiten für ein Projekt. Weitere Informationen finden Sie in der README-Datei. |
UpdateChecker | Überprüft, ob eine bestimmte Abhängigkeit aktuell ist. Weitere Informationen finden Sie in der README-Datei. |
FileUpdater | Aktualisiert eine Abhängigkeitsdatei, um die neueste Version einer bestimmten Abhängigkeit zu verwenden. Weitere Informationen finden Sie in der README-Datei. |
MetadataFinder | Sucht nach Metadaten zu einer Abhängigkeit, beispielsweise deren GitHub-URL. Weitere Informationen finden Sie in der README-Datei. |
Version | Beschreibt die Logik zum Vergleichen von Abhängigkeitsversionen. Ein Beispiel finden Sie in der Klasse „Hex-Version“. |
Requirement | Beschreibt das Format einer Abhängigkeitsanforderung (z. B. >= 1.2.3 ). Ein Beispiel finden Sie in der Hex-Requirement-Klasse. |
Der High-Level-Flow sieht folgendermaßen aus:
dependabot-omnibusDies ist ein „Meta“-Juwel, das einfach von allen anderen abhängt. Wenn Sie automatisch Unterstützung für alle Sprachen einbinden möchten, können Sie einfach dieses Juwel einbinden und Sie erhalten alles, was Sie brauchen.
Für viele Ökosysteme unterstützt Dependabot-Core private Register. Manchmal geschieht dies durch die direkte Übergabe der privaten Registrierungsdaten an die nativen Paketmanager ( npm , pip , bundler usw.), manchmal geschieht es innerhalb des Dependabot-Core Ruby-Codes.
Sequenzdiagramm
Anmeldeinformationen für die private Registrierung -> Dependabot-Core:<br />
Dependabot-Core->>Native Paketmanager:<br />
Native Paketmanager -> Paketregistrierungen:<br />
Dependabot-Core->>Paketregister:<br />
Dies ist zwar einfach und unkompliziert, stellt jedoch ein Sicherheitsrisiko für Ökosysteme dar, die die Ausführung nicht vertrauenswürdigen Codes in ihren Manifestdateien zulassen. Beispielsweise ermöglichen setup.py und .gemspec die Ausführung von nativem Python- und Ruby-Code. Wenn ein Paket im Abhängigkeitsbaum gehackt wird, könnte ein Angreifer ein bösartiges Manifest verbreiten, das den nativen Paketmanager dazu zwingt, die Creds offenzulegen.
Um dies zu verhindern, umschließen wir Dependabot-Core für den von Github ausgeführten Dependabot-Dienst mit einem Anmeldeinformations-Proxy, sodass diese privaten Registrierungsgeheimnisse Dependabot-Core niemals zugänglich gemacht werden.
Sequenzdiagramm
Dependabot-Core->>Credentials Proxy: Alle Anfragen sind nicht authentifiziert
Credentials Proxy->>Package Registries: Creds werden vom Proxy eingefügt
Notiz links von Dependabot-Core: Der Dependabot-Dienst<br />, den GitHub ausführt
Paketregistrierungen->>Anmeldeinformations-Proxy: Creds werden vom Proxy entfernt
Credentials Proxy->>Dependabot-Core: Dependabot-Core sieht niemals private Registrierungsanmeldeinformationen
Dies bedeutet auch, dass diese Creds immer noch nicht gefährdet sind, wenn Dependabot-Core jemals eine Sicherheitslücke aufweist.
Dieses Projekt kann Marken oder Logos für Projekte, Produkte oder Dienstleistungen enthalten. Die autorisierte Nutzung von GitHub-Marken oder -Logos unterliegt den GitHub-Logos und -Nutzungsbedingungen und muss diese befolgen. Die Verwendung von GitHub-Markenzeichen oder -Logos in geänderten Versionen dieses Projekts darf keine Verwirrung stiften oder GitHub-Sponsoring implizieren. Jegliche Nutzung von Marken oder Logos Dritter unterliegt den Richtlinien dieser Drittanbieter.
Dependabot und dependabot-core begannen ihr Leben als Bump und Bump Core, damals, als @hmarr und @greysteil bei GoCardless arbeiteten.
Dependabot wurde 2019 Teil von GitHub!
Veröffentlichen Sie eine neue Version in RubyGems, indem Sie den Workflow Gems - Bump Version ausführen und den Anweisungen in der Auftragszusammenfassung folgen.
Kurz gesagt wird der Prozess wie folgt aussehen:
v1.2.3 . Die Jobzusammenfassung enthält eine URL, die vorab mit der richtigen Version für Titel und Tag ausgefüllt ist.
