Rooba
/
oss-fuzz
mirror of https://github.com/google/oss-fuzz.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
oss-fuzz/projects/libbpf/project.yaml

27 lines
486 B
YAML
Raw Normal View History

[libbpf] initial integration (#6608) * [libbpf] initial integration * [libbpf] link against zlib statically it somehow helps to get around https://github.com/google/oss-fuzz/issues/6524 * [libbpf] trim headers * [libbpf] more sanitizers * [libbpf] show the commit libelf is built from to make it easier to roll back to the last known working version should something go wrong * [libbpf] pin libelf to a particular commit to avoid running into unpredictable build failures that can't be controlled by the libbpf project itself. In the future libelf should probably be built using the latest stable release at https://sourceware.org/elfutils/ftp/elfutils-latest.tar.bz2 * [libbpf] add more comment to hoppefully make it easier to make sense of the build script in the foreseeable future * [libbpf] add support for "local" mode without docker to make it easier to build the fuzz target locally: ``` cd projects/libbpf git clone https://github.com/libbpf/libbpf ./build.sh unzip -d CORPUS ./out/bpf-object-fuzzer_seed_corpus.zip ./out/bpf-object-fuzzer CORPUS/ ``` * [libbpf] more comments * [libbpf] add the maintainer's email address * [libbpf] more comments * [libbpf] install libz explicitly * [libbpf] build 4 times a day It should help to prevent OSS-Fuzz from reporting issues that have already been fixed
2021-10-22 04:30:02 +00:00
homepage: "https://github.com/libbpf/libbpf"
language: c
primary_contact: "andrii.nakryiko@gmail.com"
sanitizers:
- address
- undefined
- memory
[libbpf] turn on i386 (#7115)
2022-01-11 10:08:54 +00:00
architectures:
- x86_64
- i386
[libbpf] initial integration (#6608) * [libbpf] initial integration * [libbpf] link against zlib statically it somehow helps to get around https://github.com/google/oss-fuzz/issues/6524 * [libbpf] trim headers * [libbpf] more sanitizers * [libbpf] show the commit libelf is built from to make it easier to roll back to the last known working version should something go wrong * [libbpf] pin libelf to a particular commit to avoid running into unpredictable build failures that can't be controlled by the libbpf project itself. In the future libelf should probably be built using the latest stable release at https://sourceware.org/elfutils/ftp/elfutils-latest.tar.bz2 * [libbpf] add more comment to hoppefully make it easier to make sense of the build script in the foreseeable future * [libbpf] add support for "local" mode without docker to make it easier to build the fuzz target locally: ``` cd projects/libbpf git clone https://github.com/libbpf/libbpf ./build.sh unzip -d CORPUS ./out/bpf-object-fuzzer_seed_corpus.zip ./out/bpf-object-fuzzer CORPUS/ ``` * [libbpf] more comments * [libbpf] add the maintainer's email address * [libbpf] more comments * [libbpf] install libz explicitly * [libbpf] build 4 times a day It should help to prevent OSS-Fuzz from reporting issues that have already been fixed
2021-10-22 04:30:02 +00:00
auto_ccs:
[libbpf] add more libbpf contributors (#7562) https://github.com/libbpf/libbpf/issues/478#issuecomment-1097587752
2022-04-13 13:49:57 +00:00
- hengqi.chen@gmail.com
[libbpf] add Julia Kartseva (#7121)
2022-01-11 21:38:38 +00:00
- yulia.kartseva@gmail.com
[libbpf] initial integration (#6608) * [libbpf] initial integration * [libbpf] link against zlib statically it somehow helps to get around https://github.com/google/oss-fuzz/issues/6524 * [libbpf] trim headers * [libbpf] more sanitizers * [libbpf] show the commit libelf is built from to make it easier to roll back to the last known working version should something go wrong * [libbpf] pin libelf to a particular commit to avoid running into unpredictable build failures that can't be controlled by the libbpf project itself. In the future libelf should probably be built using the latest stable release at https://sourceware.org/elfutils/ftp/elfutils-latest.tar.bz2 * [libbpf] add more comment to hoppefully make it easier to make sense of the build script in the foreseeable future * [libbpf] add support for "local" mode without docker to make it easier to build the fuzz target locally: ``` cd projects/libbpf git clone https://github.com/libbpf/libbpf ./build.sh unzip -d CORPUS ./out/bpf-object-fuzzer_seed_corpus.zip ./out/bpf-object-fuzzer CORPUS/ ``` * [libbpf] more comments * [libbpf] add the maintainer's email address * [libbpf] more comments * [libbpf] install libz explicitly * [libbpf] build 4 times a day It should help to prevent OSS-Fuzz from reporting issues that have already been fixed
2021-10-22 04:30:02 +00:00
- evverx@gmail.com
[libbpf] add more libbpf contributors (#9245) even though libbpf bug reports on Monorail are public and mirrored on GitHub it's necessary to have access to oss-fuzz.com to view full backtraces/statistics and so on. cc @shunghsiyu
2022-12-20 14:52:42 +00:00
- shunghsiyu@gmail.com
Add Eduard Zingerman (eddyz87@gmail.com) to auto CC list for libbpf (#11883) Hello oss-fuzz maintainers, My name is Eduard Zingerman, I'm one of the maintainers for libbpf (see [here](https://github.com/torvalds/linux/blob/0106679839f7c69632b3b9833c3268c316c0a9fc/MAINTAINERS#L3898)). Could you please add me to `auto_cc` list for libbpf project, the reason I'm asking: need to see details for the following two reports: [1](https://github.com/libbpf/libbpf/issues/802), [2](https://github.com/libbpf/libbpf/issues/803). As-is I get an "Access denied" page from oss-fuzz.com when I try to open the "detailed report" links. (I am following procedure suggested [here](https://github.com/google/oss-fuzz/issues/4511), apologies if this is not the correct way to ask for access). Best regards, Eduard
2024-05-04 23:55:04 +00:00
- eddyz87@gmail.com
[libbpf] initial integration (#6608) * [libbpf] initial integration * [libbpf] link against zlib statically it somehow helps to get around https://github.com/google/oss-fuzz/issues/6524 * [libbpf] trim headers * [libbpf] more sanitizers * [libbpf] show the commit libelf is built from to make it easier to roll back to the last known working version should something go wrong * [libbpf] pin libelf to a particular commit to avoid running into unpredictable build failures that can't be controlled by the libbpf project itself. In the future libelf should probably be built using the latest stable release at https://sourceware.org/elfutils/ftp/elfutils-latest.tar.bz2 * [libbpf] add more comment to hoppefully make it easier to make sense of the build script in the foreseeable future * [libbpf] add support for "local" mode without docker to make it easier to build the fuzz target locally: ``` cd projects/libbpf git clone https://github.com/libbpf/libbpf ./build.sh unzip -d CORPUS ./out/bpf-object-fuzzer_seed_corpus.zip ./out/bpf-object-fuzzer CORPUS/ ``` * [libbpf] more comments * [libbpf] add the maintainer's email address * [libbpf] more comments * [libbpf] install libz explicitly * [libbpf] build 4 times a day It should help to prevent OSS-Fuzz from reporting issues that have already been fixed
2021-10-22 04:30:02 +00:00
main_repo: "https://github.com/libbpf/libbpf"
builds_per_day: 4
[libbpf] report bugs on GitHub and make them public by default (#7549) to hopfully make it easier to keep track of them.
2022-04-11 03:37:52 +00:00
view_restrictions: none
file_github_issue: True
Make `Centipede` a default fuzzing engine (#10109) 1. Add `centipede` to `DEFAULT_ENGINES`. 2. Remove the `fuzzing_engines` attribute from `project.yaml`s if redundant (i.e., all default engines are included in that YAML file). 3. Temporarily disable `centipede` on `c`/`c++` projects that previously use all `DEFAULT_ENGINES` (200 projects did not specify `fuzzing_engines` in `project.yaml`) so that we can gradually enable centipede later them later.
2023-04-20 23:48:45 +00:00
fuzzing_engines:
- afl
- honggfuzz
- libfuzzer