gitlab-org/security-products/protocol-fuzzer-ceयह GitLab के प्रोटोकॉल फज़िंग फ्रेमवर्क का सामुदायिक संस्करण है। यह फ्रेमवर्क कुछ सुविधाओं को हटाकर Peach Fuzzer Professional पर आधारित है।
:toc: = GitLab Protocol Fuzzer Community Edition
यह प्रोजेक्ट Peach Fuzzer Professional v4 पर आधारित है जिसे 2020 में GitLab द्वारा https://about.gitlab.com/press/releases/2020-06-11-gitlab-acquires-peach-tech-and-fuzzit-to-expand-devsecops-offering.html[अधिग्रहित किया गया था]। Peach Fuzzer Professional की कुछ विशेषताओं को हटा दिया गया है और भविष्य में GitLab के भाग के रूप में उपलब्ध कराया जाएगा। यह प्रोजेक्ट GitLab और Source Forge पर होस्ट किए गए Peach Fuzzer Community प्रोजेक्ट्स की जगह लेता है।
चूंकि यह कोड मूल रूप से Peach Tech द्वारा विकसित किया गया था, इसलिए पूरे रेपो में Peach Tech के कर्मियों, ईमेल पतों, वेबसाइटों या क्षमताओं के संदर्भ हो सकते हैं। समय के साथ इन्हें GitLab को संदर्भित करने के लिए अपडेट किया जाएगा। यदि आपको कोई मिलता है, तो कृपया स्पष्टीकरण और/या अपडेट के लिए एक MR खोलने में संकोच न करें।
कृपया बाइनरी उपलब्ध होने तक स्थानीय बिल्ड निर्देशों का पालन करें।
== रेपो लेआउट
build::
रेपो को संकलित करने के लिए बिल्ड स्क्रिप्ट।
इसमें waf (peach द्वारा उपयोग किया जाने वाला बिल्ड सिस्टम),
asciidoctor टेम्पलेट और jenkins द्वारा उपयोग की जाने वाली विभिन्न स्क्रिप्ट शामिल हैं।
एकीकरण बिल्ड के लिए।
core::
OSS और बंद स्रोत Peach के बीच सामान्य कक्षाएं और इंटरफ़ेस।
docs::
उपयोगकर्ता गाइड, डेवलपर गाइड और परीक्षण गाइड के लिए सभी दस्तावेज़।
packer::
packer (https://packer.io) द्वारा उपयोग किए जाने वाले टेम्पलेट और स्क्रिप्ट
होस्टेड परीक्षण AMI और ऑन-प्रिम परीक्षण OVA उत्पन्न करने के लिए।
pro::
Peach Professional और संबंधित अनुप्रयोगों और परीक्षणों के लिए स्रोत कोड।
tools::
बिल्ड के लिए आवश्यक स्क्रिप्ट (nunit लॉन्चर और *.exe.config जनरेटर)।
== Git वर्कफ़्लो
बिल्ड स्क्रिप्ट उम्मीद करती हैं कि सभी कमिट संदेश नियमों के एक सेट का पालन करेंगे।
संदेश निम्नलिखित में से किसी एक उपसर्ग से शुरू होने चाहिए:
new: chg: fix: dev:.
कोई मर्ज कमिट की अनुमति नहीं है, और यह अनुशंसा की जाती है कि सभी PR
एकल कमिट में समेकित किए जाएं।
कमिट संदेश की पहली पंक्ति का उपयोग ग्राहक-सामने वाले चेंजलॉग को स्वचालित रूप से उत्पन्न करने के लिए किया जाता है।
कमिट संदेश की बाद की पंक्तियों में कुछ भी हो सकता है और चेंजलॉग निर्माण के दौरान उन्हें अनदेखा किया जाता है।
यदि कमिट संदेश 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 को संकलित करने के लिए चलाया जाना चाहिए।
यह कदम लिनक्स लाइब्रेरी संकलन के ऑटोकॉन्फ चरण के अनुरूप है। +
+
Waf सभी बिल्ड निर्भरताओं का पता लगाने का प्रयास करेगा और उनके पथों को सहेजेगा।
यदि किसी विशेष वेरिएंट के लिए कोई बिल्ड निर्भरता नहीं मिल पाती है,
तो बिल्ड वेरिएंट को असमर्थित के रूप में चिह्नित किया जाएगा।
यह उपयोगी हो सकता है यदि आप केवल linux_x86_64 के लिए बिल्ड करना चाहते हैं लेकिन docs बिल्ड नहीं करना चाहते हैं। +
+
कॉन्फ़िगर चरण प्रोग्राम packt (https://fsprojects.github.io/Paket/) चलाएगा और
paket/paket.depenencies में सूचीबद्ध आवश्यकताओं का उपयोग करके nuget से सभी तृतीय-पक्ष निर्भरताएँ प्राप्त करेगा। +
+
नोट: waf configure केवल एक बार चलाने की आवश्यकता है।
Peach स्रोतों को संशोधित करने के सामान्य डेवलपर वर्कफ़्लो के लिए, आपको
इस कमांड को चलाने की आवश्यकता नहीं होगी। हालाँकि, यदि आप बिल्ड स्क्रिप्ट में बदलाव करते हैं
(build निर्देशिका में स्थित, या आपने बिल्ड टूल्स के स्थापित सेट को बदल दिया है),
तो आपको इस कमांड को पुनः चलाने की आवश्यकता होगी ताकि अपडेट किए गए टूल पथ को हल किया जा सके। +
+
टिप: यदि कोई त्रुटि होती है क्योंकि कोई आवश्यक टूल नहीं मिल पाता है, तो
बढ़ी हुई वर्बोसिटी के साथ पुनः चलाने का प्रयास करें। waf configure -v प्रदर्शित करेगा
प्रत्येक निर्भरता जो पाई जा रही है, साथ ही वह पूर्ण पथ जहाँ इसका पता चला है। +
+
कॉन्फ़िगरेशन चरण यह भी है कि एकीकरण बिल्ड संस्करण संख्या कैसे सेट करता है।
waf configure --buildtag=4.3.100 चलाकर, सभी बिल्ड कलाकृतियों पर
निर्दिष्ट बिल्डटैग के साथ मुहर लगाई जाएगी। यदि कोई विकल्प निर्दिष्ट नहीं किया गया है, तो बिल्डटैग
डिफ़ॉल्ट 0.0.0 होता है।
waf build::
यह वह कमांड है जो रिपॉजिटरी में सभी बिट्स को संकलित करेगा।
संकलन में संस्करण-मुद्रांकित फ़ाइलें उत्पन्न करना,
किसी भी स्रोत कोड ट्रांसपिलेशन को चलाना,
स्रोत को संकलित करना और परिणामों को लिंक करना शामिल है। +
+
यह कमांड लिनक्स पर make चलाने के अनुरूप है। +
+
बिल्ड चरण से सभी कलाकृतियाँ slag/{variant} निर्देशिका में समाप्त होंगी।
waf install::
यह कमांड प्रोग्राम आउटपुट, साथ ही सभी लाइब्रेरी निर्भरताओं को output/{variant} निर्देशिका में स्थापित करता है। +
+
यह कमांड लिनक्स पर make install चलाने के अनुरूप है। +
+
लिनक्स के लिए सामान्य डेवलपर वर्कफ़्लो waf install --variant=linux_x86_64_debug चलाना है
और फिर ./output/linux_x86_64_debug/bin/peach चलाना है।
=== वैकल्पिक बिल्ड कमांड
waf pkg::
यह इंस्टॉलर ज़िप उत्पन्न करता है।
Peach के लिए, दो ज़िप हैं, एक आंतरिक उपयोग के लिए (यूनिट टेस्ट/एकीकरण परीक्षण चलाना)
और एक बाहरी उपयोग के लिए (डाउनलोड साइट पर अपलोड करना)।
दोनों ज़िप output/{variant}/pkg फ़ोल्डर में आते हैं।
अंत में, यह waf कमांड स्थानीय लाइसेंस सर्वर ज़िप बनाएगा।
waf test::
सभी यूनिट टेस्ट चलाता है। Windows x64 डीबग वेरिएंट के लिए यूनिट टेस्ट चलाने के लिए, आप
waf test --variant=win_x64_debug चला सकते हैं।
waf msvs2017::
Visual Studio 2017 के साथ उपयोग के लिए सभी .csproj फ़ाइलें और Peach.sln फ़ाइल बनाता है।
waf zip:: स्थापना चरण से सभी आउटपुट को एक एकल कलाकृति में ज़िप करता है।
=== Waf नोट्स
Waf का उपयोग सिंटैक्स का पालन करता है: waf [command] [options]
सभी कमांड के लिए, एक या अधिक -v तर्क जोड़कर वर्बोसिटी बढ़ाई जा सकती है।
कॉन्फ़िगर को छोड़कर सभी कमांड के लिए, निम्नलिखित विकल्प समर्थित हैं:
--variant=xxx कमांड को उन वेरिएंट्स में फ़िल्टर करेगा जिनके नाम में 'xxx' है।
इसका मतलब है कि --variant=4_d वेरिएंट linux_x86_64_debug और win_x64_debug से मेल खाएगा।-j1 waf के कार्य समानांतरीकरण को नियंत्रित करेगा ताकि एक समय में केवल 1 कार्य चल सके।
डिफ़ॉल्ट रूप से, waf एक साथ N कार्य चलाएगा जहाँ N होस्ट पर CPU कोर की संख्या से मेल खाता है।
एक समय में केवल एक कार्य चलाना कभी-कभी बिल्ड त्रुटियों के समस्या निवारण में मदद कर सकता है।waf --help समर्थित कमांड और विकल्पों की पूरी सूची प्रदर्शित करेगा।== मर्ज अनुरोध सबमिट करना
दिशानिर्देश
. यूनिट टेस्ट पुल अनुरोध के साथ प्रदान किए जाने चाहिए . लॉगिंग का सही उपयोग . सभी मर्ज अनुरोध स्रोत कोड समीक्षा से गुजरेंगे
सुनिश्चित करें कि Peach टीम और विशेष रूप से @mikeeddington को मर्ज अनुरोध स्वीकार कराने की किसी भी समय सीमा की जानकारी है। अन्यथा मर्ज अनुरोधों को स्वीकार होने में कई महीने लगना असामान्य नहीं है।
=== लॉगिंग
Peach डीबग/ट्रेस संदेशों की लॉगिंग के लिए NLog का उपयोग करता है।
Debug:: डीबग संदेशों का संयम से उपयोग किया जाना चाहिए। ग्राहक अपने पिट्स में समस्याओं की पहचान करने के लिए --debug का उपयोग करते हैं। इस आउटपुट को संक्षिप्त रखना महत्वपूर्ण है, जिसमें अंतिम उपयोगकर्ता के लिए आवश्यक जानकारी ही प्रदर्शित हो।
Trace:: यह लॉग स्तर है जिसका उपयोग उस आउटपुट के लिए किया जाना चाहिए जो ज्यादातर Peach डेवलपर्स या किसी संभावित समस्या के निदान के दौरान चाहिए, लेकिन यह ऐसा कुछ नहीं है जिसे ग्राहक हमेशा देखना चाहेगा।
=== यूनिट टेस्ट
सभी पुल अनुरोधों में ऐसे यूनिट टेस्ट होने आवश्यक हैं जो सभी सुविधाओं का उचित कवरेज प्रदान करते हैं। NUnit हमारा यूनिट परीक्षण ढांचा है। पुल अनुरोध सबमिट करने से पहले सत्यापित करें कि सभी Peach यूनिट टेस्ट पास हो रहे हैं।
=== दस्तावेज़ीकरण
सभी शिपिंग कोड सुविधाओं के लिए उत्पाद दस्तावेज़ीकरण आवश्यक है। यह फिक्सअप या इसी तरह के लिए नया दस्तावेज़ीकरण या मौजूदा दस्तावेज़ीकरण का अद्यतन हो सकता है।