gitlab-org/security-products/protocol-fuzzer-ceهذه هي النسخة المجتمعية من إطار اختبار البروتوكولات الخاص بـ GitLab. يعتمد هذا الإطار على Peach Fuzzer Professional مع إزالة بعض الميزات.
:toc: = GitLab Protocol Fuzzer الإصدار المجتمعي
هذا المشروع مبني على Peach Fuzzer Professional v4 الذي https://about.gitlab.com/press/releases/2020-06-11-gitlab-acquires-peach-tech-and-fuzzit-to-expand-devsecops-offering.html[استحوذت عليه GitLab] في 2020. تم إزالة بعض ميزات Peach Fuzzer Professional وسيتم توفيرها كجزء من GitLab في المستقبل. يحل هذا المشروع محل مشاريع Peach Fuzzer Community المستضافة على GitLab وكذلك Source Forge.
نظرًا لأن هذا الرمز تم تطويره أصلاً بواسطة Peach Tech، فقد تكون هناك إشارات في جميع أنحاء المستودع إلى الموظفين أو عناوين البريد الإلكتروني أو المواقع الإلكترونية أو الإمكانيات الخاصة بـ Peach Tech. سيتم تحديث هذه الإشارات بمرور الوقت للإشارة إلى GitLab. إذا وجدت واحدة، فلا تتردد في فتح MR لطلب توضيح و/أو تحديثها.
يرجى اتباع تعليمات البناء المحلية حتى تصبح الملفات الثنائية متاحة.
== تخطيط المستودع
build::
نصوص بناء لتجميع المستودع.
يشمل ذلك waf (نظام البناء الذي يستخدمه Peach)،
قوالب asciidoctor، والنصوص المختلفة المستخدمة من قبل jenkins
للبناء المتكامل.
core::
الفئات والواجهات المشتركة بين Peach مفتوح المصدر والمغلق.
docs::
جميع وثائق دليل المستخدم ودليل المطور والأدلة التجريبية.
packer::
القالب والنصوص المستخدمة بواسطة packer (https://packer.io) لإنشاء
AMI التجريبي المستضاف و OVA التجريبي المحلي.
pro::
الكود المصدري لـ Peach Professional والتطبيقات والاختبارات المرتبطة به.
tools::
النصوص المطلوبة للبناء (مشغل nunit ومولد *.exe.config).
== سير عمل Git
تتوقع نصوص البناء أن تتبع جميع رسائل الالتزام مجموعة من القواعد.
يجب أن تبدأ الرسائل بأحد البادئات التالية:
new: chg: fix: dev:.
لا يُسمح بعمليات دمج، ويوصى بضغط جميع PRs
في التزام واحد.
يتم استخدام السطر الأول من رسالة الالتزام لتوليد سجل التغييرات الموجه للعملاء تلقائيًا.
يمكن أن تحتوي الأسطر اللاحقة من رسالة الالتزام على أي شيء ويتم تجاهلها أثناء توليد سجل التغييرات.
إذا بدأت رسالة الالتزام بـ dev:، فسيتم حذف الالتزام من سجل التغييرات.
يتم تصنيف الالتزامات الأخرى على أنها جديدة أو معدلة أو تم إصلاحها.
== تعليمات البناء المحلية
يدعم Peach التجميع على أجهزة Windows و Linux و OSX. يستخدم Peach waf (https://waf.io/) كنظام بناء. يدعم Waf فكرة 'متغيرات البناء' المستخدمة لتجميع Peach لمنصات وبنى مختلفة.
يستخدم Peach 11 متغير بناء مختلفًا:
Windows::
win_x86_debug win_x86_release win_x64_debug win_x64_release
Linux::
linux_x86_debug linux_x86_release linux_x86_64_debug linux_x86_64_release
OSX::
osx_debug osx_release
Documentation::
doc
يبني Waf خارج الشجرة، مما يعني وضع الملفات الوسيطة والملفات الثنائية الناتجة
في دليل مختلف عن الكود المصدري.
بالنسبة لبناء Peach، يتم وضع الملفات الوسيطة في دليل slag/{variant}
ويتم تثبيتها في دليل output/{variant}.
يبحث Waf عن ملفات wscript_build في جميع الأدلة الفرعية للجذر
ويقوم بتشغيل ما بداخلها. بالنسبة لمعظم ملفات wscript_build ذات المستوى الأعلى،
فهي تحتوي عادةً على القائمة التالية من الأدلة الفرعية للتكرار فيها.
=== متطلبات البناء على Windows:
أضف إدخالي التسجيل التاليين عبر PowerShell:
=== متطلبات البناء على Linux:
=== أوامر البناء
الأوامر الدنيا المطلوبة لتجميع Peach موضحة أدناه:
waf configure::
هذه هي الخطوة الأولى التي يجب تشغيلها لتجميع Peach.
هذه الخطوة مماثلة لمرحلة autoconf في تجميع مكتبات Linux. +
+
سيحاول Waf تحديد موقع جميع تبعيات البناء وحفظ مساراتها.
إذا تعذر تحديد موقع تبعية بناء لمتغير معين،
سيتم وضع علامة على متغير البناء على أنه غير مدعوم.
يمكن أن يكون هذا مفيدًا إذا كنت ترغب فقط في البناء من أجل linux_x86_64 ولكن لا ترغب في بناء المستندات. +
+
ستقوم مرحلة التهيئة بتشغيل برنامج paket (https://fsprojects.github.io/Paket/) وجلب
جميع تبعيات الطرف الثالث من nuget باستخدام المتطلبات المدرجة في paket/paket.dependencies. +
+
ملاحظة: waf configure يحتاج إلى التشغيل مرة واحدة فقط.
بالنسبة لسير عمل المطور العادي لتعديل مصادر Peach، لن تحتاج
إلى تشغيل هذا الأمر. ومع ذلك، إذا قمت بإجراء تغييرات على نصوص البناء
(الموجودة في دليل build، أو قمت بتغيير مجموعة أدوات البناء المثبتة،
ستحتاج إلى إعادة تشغيل هذا الأمر حتى يمكن حل مسار الأداة المحدثة. +
+
تلميح: إذا حدث خطأ لأن أداة مطلوبة لا يمكن تحديد موقعها، حاول
إعادة التشغيل مع زيادة مستوى التفصيل. waf configure -v سيعرض
كل تبعية يتم تحديد موقعها بالإضافة إلى المسار الكامل حيث تم اكتشافها. +
+
مرحلة التهيئة هي أيضًا الطريقة التي يحدد بها البناء المتكامل رقم الإصدار.
عن طريق تشغيل waf configure --buildtag=4.3.100، سيتم وضع علامة على جميع القطع الأثرية المبنية
بـ buildtag المحدد. إذا لم يتم تحديد أي خيار، فإن buildtag
الافتراضي هو 0.0.0.
waf build::
هذا هو الأمر الذي سيجمع جميع الأجزاء في المستودع.
يتضمن التجميع إنشاء ملفات موسومة بالإصدار،
وتشغيل أي تحويل للكود المصدري،
وتجميع المصدر وربط النتائج. +
+
هذا الأمر مماثل لتشغيل make على Linux. +
+
ستنتهي جميع القطع الأثرية من مرحلة البناء في دليل slag/{variant}.
waf install::
هذا الأمر يقوم بتثبيت مخرجات البرنامج، بالإضافة إلى جميع تبعيات المكتبة، في دليل output/{variant}. +
+
هذا الأمر مماثل لتشغيل make install على Linux. +
+
سير عمل المطور المعتاد على Linux هو تشغيل waf install --variant=linux_x86_64_debug
ثم تشغيل ./output/linux_x86_64_debug/bin/peach.
=== أوامر البناء الاختيارية
waf pkg::
هذا ينشئ أرشيفات التثبيت (zips).
بالنسبة لـ Peach، هناك ملفان مضغوطان، واحد للاستخدام الداخلي (تشغيل اختبارات الوحدة/اختبارات التكامل)
والآخر للاستخدام الخارجي (التحميل إلى موقع التنزيل).
يتم وضع الملفين المضغوطين في مجلد output/{variant}/pkg.
أخيرًا، سيقوم أمر waf هذا بإنشاء أرشيف خادم الترخيص المحلي.
waf test::
تشغيل جميع اختبارات الوحدة. لتشغيل اختبارات الوحدة لمتغير windows x64 debug، يمكنك تشغيل
waf test --variant=win_x64_debug.
waf msvs2017::
إنشاء جميع ملفات .csproj وملف Peach.sln لاستخدامها مع Visual Studio 2017.
waf zip:: ضغط جميع مخرجات مرحلة التثبيت في قطعة أثرية واحدة.
=== ملاحظات حول Waf
استخدام Waf يتبع الصيغة: waf [command] [options]
بالنسبة لجميع الأوامر، يمكن زيادة مستوى التفصيل بإضافة وسيط -v واحد أو أكثر.
بالنسبة لجميع الأوامر باستثناء configure، تكون الخيارات التالية مدعومة:
--variant=xxx سيقوم بتصفية الأمر للمتغيرات التي تحتوي على 'xxx' في اسمها.
هذا يعني أن --variant=4_d سيطابق المتغيرات linux_x86_64_debug و win_x64_debug.-j1 سيتحكم في التوازي للمهام في waf بحيث يمكن تشغيل مهمة واحدة فقط في كل مرة.
افتراضيًا، سيقوم waf بتشغيل N مهمة في وقت واحد حيث N يقابل عدد وحدات المعالجة المركزية على المضيف.
تشغيل مهمة واحدة فقط في كل مرة يمكن أن يساعد أحيانًا في استكشاف أخطاء البناء وإصلاحها.waf --help سيعرض القائمة الكاملة للأوامر والخيارات المدعومة.== تقديم طلبات الدمج
إرشادات
. يجب توفير اختبارات الوحدة مع طلب السحب . الاستخدام الصحيح للتسجيل . ستخضع جميع طلبات الدمج لمراجعة الكود المصدري
تأكد من أن فريق Peach وخاصة @mikeeddington على علم بأي مواعيد نهائية لقبول طلبات الدمج. ليس من غير المألوف أن تستغرق طلبات الدمج عدة أشهر ليتم قبولها بخلاف ذلك.
=== التسجيل
يستخدم Peach NLog لتسجيل رسائل التصحيح/التتبع.
Debug:: يجب استخدام رسائل التصحيح بشكل محدود. يستخدم العملاء --debug لتحديد المشكلات في pits الخاصة بهم. من الضروري الحفاظ على هذا الإخراج موجزًا، مع المعلومات التي يحتاجها المستخدم النهائي فقط.
Trace:: هذا هو مستوى التسجيل الذي يجب استخدامه للإخراج الذي يرغب فيه مطورو Peach بشكل أساسي أو عند تشخيص مشكلة محتملة، ولكن ليس شيئًا يرغب العميل في رؤيته دائمًا.
=== اختبارات الوحدة
جميع طلبات السحب مطلوب أن تحتوي على اختبارات وحدة توفر تغطية معقولة لجميع الميزات. NUnit هو إطار اختبار الوحدة الخاص بنا. قبل تقديم طلب سحب، تحقق من اجتياز جميع اختبارات الوحدة لـ Peach.
=== التوثيق
جميع ميزات الكود التي يتم تسليمها تتطلب توثيقًا للمنتج. يمكن أن يكون هذا توثيقًا جديدًا لإصلاح أو إضافة مشابهة أو تحديثًا للتوثيق الحالي.