gitlab-org/security-products/protocol-fuzzer-ce이것은 GitLab의 프로토콜 퍼징 프레임워크의 커뮤니티 에디션입니다. 이 프레임워크는 일부 기능이 제거된 Peach Fuzzer Professional을 기반으로 합니다.
:toc:
= GitLab 프로토콜 퍼저 커뮤니티 에디션
이 프로젝트는 2020년에 https://about.gitlab.com/press/releases/2020-06-11-gitlab-acquires-peach-tech-and-fuzzit-to-expand-devsecops-offering.html[GitLab이 인수한] Peach Fuzzer Professional v4를 기반으로 합니다. Peach Fuzzer Professional의 일부 기능은 제거되었으며 향후 GitLab의 일부로 제공될 예정입니다. 이 프로젝트는 GitLab 및 Source Forge에 호스팅된 Peach Fuzzer 커뮤니티 프로젝트를 대체합니다.
이 코드는 원래 Peach Tech에서 개발되었으므로, 저장소 전체에 Peach Tech 특정 직원, 이메일 주소, 웹사이트 또는 기능에 대한 참조가 있을 수 있습니다. 이러한 내용은 시간이 지남에 따라 GitLab을 참조하도록 업데이트될 예정입니다. 발견하시면 언제든지 MR을 열어 설명을 요청하거나 업데이트해 주세요.
바이너리가 제공될 때까지 로컬 빌드 지침을 따르십시오.
== 저장소 구조
build::
저장소 컴파일을 위한 빌드 스크립트. 여기에는 waf(Peach에서 사용하는 빌드 시스템), asciidoctor 템플릿, 그리고 통합 빌드를 위해 Jenkins에서 사용하는 다양한 스크립트가 포함됩니다.
core::
OSS와 폐쇄 소스 Peach 간의 공통 클래스 및 인터페이스.
docs::
사용자 가이드, 개발자 가이드 및 평가판 가이드에 대한 모든 문서.
packer::
호스팅 평가판 AMI 및 온프레미스 평가판 OVA를 생성하기 위해 packer(https://packer.io)에서 사용하는 템플릿 및 스크립트.
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는 아웃 오브 트리(out-of-tree) 방식으로 빌드합니다. 즉, 중간 파일 및 출력 바이너리가 소스 코드와 다른 디렉터리에 배치됩니다. Peach 빌드의 경우 중간 파일은 slag/{variant} 디렉터리에 배치되고 output/{variant} 디렉터리에 설치됩니다.
Waf는 루트의 모든 하위 디렉터리에서 wscript_build 파일을 찾아 그 안에 있는 내용을 실행합니다. 대부분의 최상위 wscript_build 파일은 일반적으로 재귀적으로 들어갈 하위 디렉터리 목록만 포함합니다.
=== Windows 빌드 필수 구성 요소:
다음 두 레지스트리 항목을 PowerShell을 통해 추가하십시오:
=== Linux 빌드 필수 구성 요소:
=== 빌드 명령
Peach 컴파일에 필요한 최소 명령은 아래와 같습니다:
waf configure::
이것은 Peach를 컴파일하기 위해 먼저 실행해야 하는 첫 번째 단계입니다. 이 단계는 리눅스 라이브러리 컴파일의 autoconf 단계와 유사합니다. +
+
Waf는 모든 빌드 종속성을 찾으려 시도하고 해당 경로를 저장합니다. 특정 변형에 대해 빌드 종속성을 찾을 수 없는 경우 해당 빌드 변형은 지원되지 않는 것으로 표시됩니다. 이는 linux_x86_64만 빌드하고 docs는 빌드하지 않으려는 경우 유용할 수 있습니다. +
+
configure 단계는 packt (https://fsprojects.github.io/Paket/) 프로그램을 실행하고 paket/paket.depenencies에 나열된 요구 사항을 사용하여 nuget에서 모든 타사 종속성을 가져옵니다. +
+
참고: waf configure는 한 번만 실행하면 됩니다. 일반적인 개발자 워크플로우(Peach 소스 수정)에서는 이 명령을 다시 실행할 필요가 없습니다. 그러나 빌드 스크립트(build 디렉터리에 있음)를 변경하거나 설치된 빌드 도구 세트를 변경한 경우 업데이트된 도구 경로를 확인하기 위해 이 명령을 다시 실행해야 합니다. +
+
팁: 필요한 도구를 찾을 수 없어 오류가 발생하는 경우, 상세 수준을 높여 다시 실행해 보십시오. waf configure -v는 찾고 있는 모든 종속성과 감지된 전체 경로를 표시합니다. +
+
구성 단계는 통합 빌드가 버전 번호를 설정하는 방법이기도 합니다. waf configure --buildtag=4.3.100을 실행하면 모든 빌드 아티팩트에 지정된 buildtag가 스탬프됩니다. 옵션을 지정하지 않으면 buildtag는 기본적으로 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::
설치 프로그램 zip을 생성합니다. Peach의 경우 두 개의 zip이 있습니다. 하나는 내부 사용(단위 테스트/통합 테스트 실행)용이고 다른 하나는 외부 사용(다운로드 사이트에 업로드)용입니다. 두 zip은 output/{variant}/pkg 폴더에 저장됩니다. 마지막으로 이 waf 명령은 로컬 라이선스 서버 zip을 생성합니다.
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 인수를 추가하여 상세 수준을 높일 수 있습니다. configure를 제외한 모든 명령에 대해 다음 옵션이 지원됩니다:
--variant=xxx는 이름에 'xxx'가 포함된 변형으로 명령을 필터링합니다. 따라서 --variant=4_d는 linux_x86_64_debug 및 win_x64_debug 변형과 일치합니다.-j1은 한 번에 하나의 작업만 실행할 수 있도록 waf의 작업 병렬화를 제어합니다. 기본적으로 waf는 호스트의 CPU 코어 수에 해당하는 N개의 작업을 동시에 실행합니다. 한 번에 하나의 작업만 실행하면 빌드 오류를 해결하는 데 도움이 될 수 있습니다.waf --help는 지원되는 모든 명령 및 옵션의 전체 목록을 표시합니다.== 병합 요청 제출
가이드라인
. 단위 테스트는 풀 리퀘스트와 함께 제공되어야 합니다. . 로깅의 올바른 사용 . 모든 병합 요청은 소스 코드 검토를 거칩니다.
Peach 팀, 특히 @mikeeddington이 병합 요청 수락 마감일을 인지하고 있는지 확인하십시오. 그렇지 않으면 병합 요청이 수락되는 데 몇 달이 걸리는 경우가 드물지 않습니다.
=== 로깅
Peach는 디버그/추적 메시지 로깅에 NLog를 사용합니다.
Debug:: 디버그 메시지는 드물게 사용해야 합니다. 고객은 --debug를 사용하여 퍼징 대상(pits)의 문제를 식별합니다. 이 출력을 간결하게 유지하고 최종 사용자에게 필요한 정보만 표시하는 것이 중요합니다.
Trace:: 이 로그 수준은 주로 Peach 개발자가 필요로 하거나 잠재적 문제 진단 시 원하는 출력에 사용해야 하며, 고객이 항상 보고 싶어하지 않는 내용입니다.
=== 단위 테스트
모든 풀 리퀘스트는 모든 기능에 대해 합리적인 범위를 제공하는 단위 테스트를 포함해야 합니다. NUnit은 저희의 단위 테스트 프레임워크입니다. 풀 리퀘스트를 제출하기 전에 모든 Peach 단위 테스트가 통과하는지 확인하십시오.
=== 문서
모든 출시 코드 기능에는 제품 문서가 필요합니다. 이는 수정 또는 유사한 내용에 대한 새 문서이거나 기존 문서의 업데이트일 수 있습니다.