dependabot core
v0.289.0
مرحبًا بكم في منزل Dependabot العام.
Dependabot-Core هي المكتبة التي تقع في قلب تحديثات أمان/إصدار Dependabot.
استخدمه لإنشاء طلبات سحب تلقائية وتحديث التبعيات للمشروعات المكتوبة بلغات Ruby وJavaScript وPython وPHP وDart وElixir وElm وGo وRust وJava و.NET. ويمكنه أيضًا تحديث وحدات git الفرعية وملفات Docker وملفات Terraform. تشمل الميزات:
يعرف معظم الأشخاص خدمة Dependabot التي تعمل على GitHub.com وGitHub Enterprise. يعد تمكين ذلك أمرًا بسيطًا مثل التحقق من ملف التكوين dependabot.yml في دليل .github الخاص بمستودعك.
ومع ذلك، إذا كنت تريد تشغيل إصدار مخصص من Dependabot أو تشغيله على نظام أساسي آخر، فلن يتم استبعادك. يوفر هذا الريبو المنطق اللازم لاستضافة Dependabot المستقل الخاص بك. وهو يدعم حاليًا فتح طلبات السحب مقابل المستودعات المستضافة على GitHub وGithub Enterprise وAzure DevOps وGitLab وBitBucket وAWS CodeCommit.
Dependabot-Core عبارة عن مكتبة، لذا ستحتاج إلى برنامج نصي لنقطة الدخول من نوع ما. فيما يلي بعض الأمثلة لمساعدتك على البدء.
ملاحظة: إذا كنت تتطلع إلى تشغيل Dependabot محليًا لأغراض التطوير/تصحيح الأخطاء، فراجع دليل التطوير.
يوفر Repo Dependabot-script مجموعة من أمثلة البرامج النصية لتكوين مكتبة Dependabot-Core. الغرض منه هو أن يكون نقطة انطلاق للمستخدمين المتقدمين لتشغيل إصدار مستضاف ذاتيًا من Dependabot ضمن مشاريعهم الخاصة.
ملاحظة: لقد قمنا مؤخرًا بإعادة هيكلة صورة عامل الإرساء المتجانسة المستخدمة داخل مكتبة Dependabot Core إلى صورة واحدة لكل نظام بيئي. لسوء الحظ، أدى ذلك إلى تعطل البرامج النصية التابعة لـdependabot، ولم يكن لدينا الوقت لتحديثها بعد. نحن على علم بالمشكلة ونأمل أن نقدم حلاً قريبًا.
تعد Dependabot CLI أداة أحدث قد تحل في النهاية محل dependabot-script في حالات الاستخدام المستقلة. على الرغم من أنه يخلق اختلافات في التبعية، إلا أنه يفتقد حاليًا المنطق لتحويل هذه الاختلافات إلى علاقات عامة فعلية. ومع ذلك، قد يكون مفيدًا للمستخدمين المتقدمين الذين يبحثون عن أمثلة حول كيفية اختراق Dependabot.
في بيئة مثل GitHub حيث يتم تشغيل Dependabot في حاوية، إذا كنت تريد تغيير عملية البناء أو التثبيت اعتمادًا على ما إذا كان Dependabot يقوم بالتحقق، فيمكنك تحديد ذلك من خلال وجود متغير بيئة DEPENDABOT .
هل تريد أن تقدم لنا تعليقات حول Dependabot، أو تساهم فيها؟ هذا عظيم - شكرا جزيلا لك!
يجب أن تكون معظم تقارير الأخطاء مصحوبة برابط إلى مستودع عام يعيد إنتاج المشكلة. قد يتم إغلاق تقارير الأخطاء التي لا يمكن إعادة إنتاجها في مستودع عام باستخدام أداة CLI أو البرنامج النصي للتشغيل الجاف باعتبارها "لا يمكن إعادة إنتاجها".
إن أداة تتبع المشكلات لدينا نشطة للغاية، ونتيجة لذلك، هناك احتمال كبير أن يقوم شخص ما بتقديم نفس المشكلة بالفعل. إذا كان الأمر كذلك، يرجى التصويت لصالح هذه المشكلة، لأننا نستخدم؟ ردود الفعل على القضايا كإشارة واحدة لقياس تأثير طلب الميزة أو الخطأ.
ومع ذلك، يرجى عدم ترك تعليقات لا تساهم بأي شيء جديد في المناقشة. للحصول على التفاصيل، راجع https://github.com/golang/go/wiki/NoPlusOne. هذا مفتوح المصدر، إذا رأيت شيئًا تريد إصلاحه، يسعدنا تدريبك من خلال المساهمة بطلب سحب لإصلاحه.
أداة تعقب المشكلات مخصصة فقط للمشكلات المتعلقة بمنطق التحديث الخاص بـ Dependabot. بدلاً من ذلك، يجب تقديم المشكلات المتعلقة بالتنبيهات الأمنية أو رسم التبعية كمناقشة لـ Code Security.
القاعدة الأساسية الجيدة هي أنه إذا كانت لديك أسئلة حول الفرق في العلاقات العامة، فهذا مكانه هنا.
إذا كنت تعتقد أنك عثرت على ثغرة أمنية في Dependabot، فيرجى مراجعة سياسة الأمان الخاصة بنا للحصول على تفاصيل حول الكشف عنها لبرنامج GitHub Bug Bounty، حتى نتمكن من العمل على حل المشكلة قبل الكشف عنها علنًا.
هل تريد المساهمة في Dependabot؟ هذا عظيم - شكرا جزيلا لك!
سير عمل المساهمة:
يرجى الرجوع إلى إرشادات المساهمة لمزيد من المعلومات.
إذا كنت مهتمًا بالمساهمة في دعم نظام بيئي جديد، فيرجى الرجوع إلى إرشادات المساهمة للحصول على مزيد من المعلومات.
الخطوة الأولى لتصحيح مشكلة ما أو كتابة ميزة جديدة هي تشغيل بيئة التطوير. نحن نقدم غلاف مطور مخصصًا قائمًا على Docker والذي يتعامل مع جميع التبعيات المطلوبة. في معظم الحالات، هذه هي أفضل طريقة للعمل مع المشروع.
يستخدم غلاف المطور وحدات تخزين الصوت لدمج تغييراتك المحلية في كود مصدر Dependabot. بهذه الطريقة يمكنك التحرير محليًا باستخدام المحرر المفضل لديك وستنعكس التغييرات على الفور داخل حاوية عامل الإرساء لإجراء عمليات التشغيل الجافة أو تنفيذ الاختبارات. ملاحظة: راجع التحذير حول تحرير البرامج النصية المساعدة لمدير الحزم الأصلي.
يقوم البرنامج النصي لتشغيل غلاف المطور ببناء صور عامل الإرساء من البداية إذا لم يتمكن من العثور عليها محليًا. قد يستغرق هذا بعض الوقت.
تخطي الانتظار عن طريق سحب الصورة المعدة مسبقًا للنظام البيئي الذي تريد العمل عليه. يستخدم اسم الصورة اسم النظام البيئي YAML لتحديد النظام البيئي. على سبيل المثال، بالنسبة لوحدات Go، اسم YAML هو gomod :
$ docker pull ghcr.io/dependabot/dependabot-updater-gomodملحوظة: الصور المعدة مسبقًا متاحة حاليًا فقط لبنية AMD64 / Intel. سيتم تشغيلها على ARM، ولكنها أبطأ بمقدار 2x-3x مما لو كنت تقوم يدويًا بإنشاء صور خاصة بـ ARM.
بعد ذلك، قم بتشغيل غلاف المطور، مع تحديد النظام البيئي المطلوب باستخدام اسم دليل المستوى الأعلى للنظام البيئي في هذا المشروع . على سبيل المثال، بالنسبة إلى Go Modules، يُسمى دليل المستوى الأعلى 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 packageعادةً ما يكون Quickstart هو كل ما تحتاجه، ولكن في بعض الأحيان ستحتاج إلى إعادة بناء الصور الأساسية.
على سبيل المثال، على الرغم من أننا لم ننشر بعد صورًا خاصة بـ ARM، إذا كنت تعمل على نظام أساسي يعتمد على ARM، فإننا نوصي بإنشاء الصور يدويًا لأن الحاويات الناتجة تعمل بشكل أسرع بكثير.
يعمل غلاف المطور ضمن صورة عامل إرساء Dependabot Development، والتي تم إنشاؤها فوق صورة النظام البيئي.
مخطط انسيابي LR
A["docker-dev-shell script"] --> B("صورة عامل ميناء تطوير Dependabot")
B --> C("صورة عامل إرساء النظام البيئي لـ Dependabot Updater (خاصة بالنظام البيئي)")
C --> D("صورة عامل الإرساء الأساسية لمحدث Dependabot")
تتطلب التغييرات التي يتم إجراؤها على ملفات عامل الإرساء لأي من هذه الصور إنشاء صورة واحدة أو أكثر محليًا حتى تنعكس في غلاف التطوير.
الطريقة البسيطة والبطيئة هي حذف أي صور موجودة ثم تشغيل bin/docker-dev-shell الذي يقوم بإنشاء الصور المفقودة تلقائيًا.
الطريقة الأسرع هي سحب جميع الصور المعدة مسبقًا والتي تعد تبعيات للصورة التي تحتاج إلى بنائها بالفعل. ل(إعادة) بناء واحدة محددة:
الصورة الأساسية للمحدث:
$ docker pull ghcr.io/dependabot/dependabot-updater-core # OR
$ docker build -f Dockerfile.updater-core . # recommended on ARMصورة النظام البيئي للمحدث:
$ docker pull ghcr.io/dependabot/dependabot-updater-gomod # OR
$ script/build go_modules # recommended on ARM حاوية التطوير باستخدام علامة --rebuild :
$ bin/docker-dev-shell go_modules --rebuildتستفيد العديد من حزم Dependabot من "المساعدين الأصليين"، وهي ملفات تنفيذية صغيرة باللغة المضيفة.
لا تنعكس التغييرات التي يتم إجراؤها على هذه الملفات تلقائيًا داخل حاوية التطوير.
بمجرد إجراء أي تعديلات على ملفات المساعد، قم بتشغيل البرنامج النصي للإنشاء المناسب لتحديث الإصدار المثبت بالتغييرات التي أجريتها كما يلي:
$ bin/docker-dev-shell bundler
= > running docker development shell
$ bundler/helpers/v2/build
$ bin/dry-run.rb bundler dependabot/demo --dir= " /ruby "لعرض السجلات والملفات القياسية من مساعدي مدير الحزم الأصليين، راجع تصحيح أخطاء المساعدين الأصليين.
الخطوة الأولى لتصحيح الأخطاء هي تشغيل بيئة التطوير.
ضمن بيئة التطوير، لديك خياران لمحاكاة مهمة تحديث التبعية: يمكنك استخدام أداة CLI المطورة حديثًا أو البرنامج النصي الأصلي للتشغيل الجاف.
Dependabot CLI هي أداة تم تطويرها حديثًا تتضمن GitHub Credentials Proxy لمحاكاة أكثر واقعية لما يحدث داخل خدمة Dependabot-at-GitHub عند التحدث إلى السجلات الخاصة.
يحتوي على دليل تصحيح أخطاء مخصص، بما في ذلك دعم الدخول إلى مصحح أخطاء روبي.
ملاحظة: قبل تشغيل البرنامج النصي للتشغيل الجاف، ستحتاج إلى تشغيل بيئة التطوير.
يمكنك استخدام البرنامج النصي bin/dry-run.rb لمحاكاة مهمة تحديث التبعية، وطباعة الفرق الذي سيتم إنشاؤه على الجهاز. يتطلب الأمر وسيطتين موضعيتين: مدير الحزم واسم GitHub repo (بما في ذلك الحساب):
$ 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
...يدعم البرنامج النصي Dry-Run العديد من الخيارات الأخرى، وجميعها موثقة في الجزء العلوي من التعليمات البرمجية المصدر للبرنامج النصي. على سبيل المثال:
LOCAL_GITHUB_ACCESS_TOKEN="fake-GitHub-PAT" يسمح بتحديد رمز الوصول الشخصي لـ GitHub (PAT) لتجنب تحديد المعدل.--dir="path/to/subdir/containing/manifest مطلوب إذا كان ملف البيان موجودًا في دليل فرعي.--dep="dep-name-that-I-want-to-test" يسمح بتحديد قسم واحد لمحاولة التحديث ويتم تجاهل جميع الآخرين.--cache=files يسمح بالتخزين المؤقت لملفات dep عن بعد محليًا لإعادة التشغيل بشكل أسرع عند اختبار تغييرات المنطق المحلي.--updater-options=feature_flag_name يسمح بتمرير إشارات الميزات.فيما يلي مثال لكيفية ربط كل هذه العناصر معًا
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 يمكنك إضافة عبارة debugger في أي مكان في كود روبي، على سبيل المثال:
def latest_resolvable_version
debugger
latest_version_finder . latest_version
endعند تنفيذ المهمة، سيتم فتح مصحح أخطاء روبي. يجب أن يبدو مثل هذا:
[ 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 ) في هذه المطالبة، يمكنك تشغيل أوامر مصحح الأخطاء للتنقل، أو إدخال الأساليب والمتغيرات لمعرفة ما تحتويه. حاول إدخال dependency لمعرفة التبعية التي يعمل عليها Dependabot حاليًا.
ملاحظة: أثناء وجودك في مصحح الأخطاء، لن يتم التقاط التغييرات التي تم إجراؤها على التعليمات البرمجية المصدر. سيكون عليك إنهاء جلسة تصحيح الأخطاء وإعادة تشغيلها.
عندما تقوم بتصحيح مشكلة ما، غالبًا ما تحتاج إلى إلقاء نظرة خاطفة على هذه البرامج النصية التي يتم تشغيلها في عملية منفصلة.
اطبع جميع بيانات السجل من المساعدين الأصليين باستخدام DEBUG_HELPERS=true :
DEBUG_HELPERS=true bin/dry-run.rb bundler dependabot/demo --dir= " /ruby " قم بإيقاف التنفيذ مؤقتًا لتصحيح وظيفة مساعد أصلية واحدة باستخدام DEBUG_FUNCTION=<function name> . ترتبط الوظيفة باسم وظيفة مساعدة أصلية، على سبيل المثال، إحدى الوظائف في bundler/helpers/v2/lib/functions.rb .
عند تنفيذ هذه الوظيفة، يتم إدخال debugger ، مما يؤدي إلى إيقاف تنفيذ البرنامج النصي bin/dry-run.rb مؤقتًا، وهذا يترك دليل التحديثات الحالية tmp في مكانه، مما يسمح لك بإدخال cd في الدليل وتشغيل وظيفة المساعد الأصلي مباشرةً:
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 انسخ وقم بتشغيل cd... الأمر:
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 يجب أن يقوم هذا بتسجيل الخروج من وظيفة parsed_gemfile :
{ "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" } ] }ضع في اعتبارك أنه على عكس التغييرات التي يتم إجراؤها على مصدر روبي، فإن التغييرات التي يتم إجراؤها على جهازك المضيف على التعليمات البرمجية المصدر للمساعدين الأصليين لا تتم مزامنتها مع حاوية التطوير. لذلك لديك خياران لتحرير المساعد الأصلي:
vi /opt/bundler/v1/lib/functions/file_parser.rb . ثم أعد تشغيل cd... الأمر. هذه هي أسرع طريقة لتصحيح الأخطاء، ولكن لن يتم حفظ أي تغييرات خارج الحاوية. ignore معظم الأنظمة البيئية في Dependabot-Core الشروط التي تسمح للمستخدم بتحديد أسماء التبعيات أو الإصدارات لاستبعادها من الترقيات. تصف مستندات خدمة Dependabot في GitHub الميزة بمزيد من التفاصيل.
يدعم Dependabot CLI تمرير شروط التجاهل كجزء من تعريف الوظيفة. انظر المثال.
يدعم البرنامج النصي للتشغيل الجاف تمرير شرط تجاهل واحد أو أكثر عبر env var IGNORE_CONDITIONS :
IGNORE_CONDITIONS= ' [{"dependency-name":"*","update-types": ["version-update:semver-major"]}] '
bin/dry-run.rb docker test_org/test-dependabot `تدعم العديد من الأنظمة البيئية في Dependabot-Core التحديثات الأمنية. هذه هي نموذج خاص لتحديث الإصدار حيث يتم تمرير اسم التبعية ونطاق الإصدارات الضعيفة. وسيحاول Dependabot-Core ترقية أي مثيل لتلك التبعية إلى الحد الأدنى من الإصدار غير المعرض للثغرات الأمنية. وهذا على النقيض من تحديث الإصدار العادي الذي يحاول التحديث إلى الإصدار الأحدث .
يسمح env var SECURITY_ADVISORIES بتمرير إشعار تنبيه أمان واحد أو أكثر إلى البرنامج النصي للتشغيل الجاف لمحاكاة التحديث الأمني:
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 " يوجد دعم مدمج للاستفادة من قدرة Visual Studio Code على تصحيح الأخطاء داخل حاوية Docker. بعد تثبيت ملحق Dev Containers الموصى به، ما عليك سوى الضغط على Ctrl+Shift+P ( ⇧⌘P على نظام التشغيل macOS) وتحديد Dev Containers: Reopen in Container . يمكنك أيضًا الوصول إلى القائمة المنسدلة من خلال النقر على الزر الأخضر الموجود في الركن الأيسر السفلي من المحرر. إذا لم تكن صورة Docker للتطوير موجودة على جهازك، فسيتم إنشاؤها تلقائيًا. بمجرد الانتهاء من ذلك، ابدأ تكوين Debug Dry Run (F5) وستتم مطالبتك بتحديد مدير الحزم والمستودع لإجراء التشغيل التجريبي عليهما. لا تتردد في وضع نقاط التوقف على الكود.
يوجد أيضًا دعم لتصحيح أخطاء عمليات الاختبار الفردية عن طريق تشغيل تكوين Debug Tests (F5) وسيُطلب منك تحديد نظام بيئي وتوفير مسار rspec.
Clone Repository ... الخاصة بملحق Remote Containers حاليًا بعض الوظائف وبالتالي فهي غير مدعومة. يتعين عليك استنساخ المستودع يدويًا واستخدام الأمر Reopen in Container أو Open Folder in Container...
بمجرد تشغيل بيئة التطوير لنظام بيئي معين، قم بتنفيذ الاختبارات لهذا النظام البيئي عن طريق تشغيل rspec spec داخل مجلد النظام البيئي هذا، على سبيل المثال
$ cd go_modules
$ rspec specيمكنك أيضًا قصر الاختبارات على الملف الذي تعمل عليه فقط، أو الاختبارات التي فشلت سابقًا فقط، على سبيل المثال:
$ rspec spec/dependabot/file_updaters/elixir --only-failures يتم فرض الأسلوب بواسطة RuboCop. للتحقق من وجود انتهاكات للأسلوب، ما عليك سوى تشغيل rubocop في كل حزمة من الحزم، على سبيل المثال
$ cd go_modules
$ rubocop يمكنك إنشاء ملف تعريف للتشغيل الجاف عن طريق تمرير علامة --profile عند تشغيله، أو وضع علامة على اختبار rspec باستخدام :profile . سيؤدي هذا إلى إنشاء ملف stackprof-<datetime>.dump في المجلد tmp/ ، ويمكنك إنشاء مخطط لهب من هذا عن طريق تشغيل:
stackprof --d3-flamegraph tmp/stackprof- < data or spec name > .dump > tmp/flamegraph.htmlDependabot-Core عبارة عن مجموعة من حزم Ruby (الأحجار الكريمة)، والتي تحتوي على منطق تحديث التبعيات بعدة لغات.
dependabot-common تحتوي الحزمة common على جميع الوظائف ذات الأغراض العامة/المشتركة. على سبيل المثال، الكود الخاص بإنشاء طلبات السحب لمختلف الأنظمة الأساسية المدعومة موجود هنا، كما هو الحال مع معظم المنطق الخاص بالتعامل مع تبعيات Git (حيث تدعم معظم اللغات تبعيات Git بطريقة أو بأخرى). هناك أيضًا فئات أساسية محددة لكل من الاهتمامات الرئيسية المطلوبة لتنفيذ الدعم للغة أو مدير الحزم.
dependabot-{package-manager}هناك جوهرة لكل مدير حزم أو لغة يدعمها Dependabot. كحد أدنى، ستطبق كل من هذه الأحجار الكريمة الفئات التالية:
| خدمة | وصف |
|---|---|
FileFetcher | جلب ملفات التبعية ذات الصلة لمشروع (على سبيل المثال، Gemfile و Gemfile.lock ). راجع التمهيدي لمزيد من التفاصيل. |
FileParser | يوزع ملف التبعية ويستخرج قائمة التبعيات للمشروع. راجع التمهيدي لمزيد من التفاصيل. |
UpdateChecker | التحقق مما إذا كانت التبعية المحددة محدثة. راجع التمهيدي لمزيد من التفاصيل. |
FileUpdater | يقوم بتحديث ملف التبعية لاستخدام أحدث إصدار من التبعية المحددة. راجع التمهيدي لمزيد من التفاصيل. |
MetadataFinder | يبحث عن البيانات التعريفية المتعلقة بالتبعية، مثل عنوان URL الخاص بـ GitHub. راجع التمهيدي لمزيد من التفاصيل. |
Version | يصف المنطق لمقارنة إصدارات التبعية. راجع فئة الإصدار السداسي للحصول على مثال. |
Requirement | يصف تنسيق متطلبات التبعية (على سبيل المثال >= 1.2.3 ). راجع فئة المتطلبات السداسية للحصول على مثال. |
يبدو التدفق عالي المستوى كما يلي:
dependabot-omnibusهذه جوهرة "فوقية"، تعتمد ببساطة على كل الجوهرة الأخرى. إذا كنت تريد تضمين الدعم لجميع اللغات تلقائيًا، فيمكنك فقط تضمين هذه الجوهرة وستحصل على كل ما تحتاجه.
بالنسبة للعديد من الأنظمة البيئية، يدعم Dependabot-Core السجلات الخاصة. يحدث هذا أحيانًا عن طريق تمرير بيانات اعتماد التسجيل الخاص مباشرةً إلى مديري الحزم الأصليين ( npm ، pip ، و bundler ، وما إلى ذلك)، وفي أحيان أخرى يحدث ذلك ضمن كود Dependabot-Core Ruby.
مخطط تسلسل
بيانات اعتماد السجل الخاص->>Dependabot-Core:<br />
Dependabot-Core->>مديرو الحزم الأصليون:<br />
مديرو الحزم الأصلية->>سجلات الحزم:<br />
Dependabot-Core->>سجلات الحزمة:<br />
على الرغم من أنه بسيط ومباشر، إلا أنه يمثل خطرًا أمنيًا على الأنظمة البيئية التي تسمح بتشغيل تعليمات برمجية غير موثوقة داخل ملفات البيان الخاصة بها. على سبيل المثال، يسمح setup.py و .gemspec بتشغيل كود Python وRuby الأصلي. إذا تم اختراق حزمة في شجرة التبعية، فيمكن للمهاجم دفع بيان ضار يجبر مدير الحزم الأصلي على كشف الاعتمادات.
وللحماية من ذلك، بالنسبة لخدمة Dependabot التي يديرها Github، فإننا نغلف Dependabot-Core بوكيل بيانات الاعتماد بحيث لا يتم كشف أسرار التسجيل الخاصة هذه أبدًا لـ Dependabot-Core.
مخطط تسلسل
Dependabot-Core- >> وكيل بيانات الاعتماد: لم تتم مصادقة جميع الطلبات
وكيل بيانات الاعتماد->>سجلات الحزم: يتم إدخال الاعتمادات بواسطة الوكيل
ملاحظة على يسار Dependabot-Core: خدمة Dependabot<br /> التي يقوم GitHub بتشغيلها
سجلات الحزمة - >> وكيل بيانات الاعتماد: يتم تجريد الوكيل من الاعتمادات
وكيل بيانات الاعتماد->>Dependabot-Core: لا يرى Dependabot-Core أبدًا بيانات اعتماد التسجيل الخاصة
وهذا يعني أيضًا أنه إذا كان لدى Dependabot-Core ثغرة أمنية، فإن هذه الاعتمادات لا تزال غير معرضة لخطر الانكشاف.
قد يحتوي هذا المشروع على علامات تجارية أو شعارات للمشاريع أو المنتجات أو الخدمات. يخضع الاستخدام المصرح به للعلامات التجارية أو الشعارات الخاصة بـ GitHub ويجب أن يتبع شعارات واستخدامات GitHub. يجب ألا يتسبب استخدام العلامات التجارية أو الشعارات الخاصة بـ GitHub في الإصدارات المعدلة من هذا المشروع في حدوث ارتباك أو الإشارة ضمنًا إلى رعاية GitHub. ويخضع أي استخدام لعلامات تجارية أو شعارات تابعة لجهات خارجية لسياسات تلك الجهات الخارجية.
بدأ Dependabot وdependabot-core حياتهما كـ Bump وBump Core، عندما كان @hmarr و@greysteil يعملان في GoCardless.
أصبح Dependabot جزءًا من GitHub في عام 2019!
انشر إصدارًا جديدًا إلى RubyGems عن طريق تشغيل سير عمل Gems - Bump Version واتباع الإرشادات الموجودة في ملخص الوظيفة.
باختصار ستكون العملية كالتالي:
v1.2.3 . يحتوي ملخص الوظيفة على عنوان URL تمت تعبئته مسبقًا بالإصدار الصحيح للعنوان والعلامة.
