<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail --> Hi Maintainers,
I have worked a bit on setting fuzzing up for Kamailio by way of OSS-Fuzz. Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects, and it would be great to have Kamailio integrated. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid.
In this PR https://github.com/google/oss-fuzz/pull/5279 I have done exactly that, namely created the necessary logic from an OSS-Fuzz perspective to integrate Kamailio. If you would like to integrate, could you please provide a set of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. The emails should be linked to a Google account in order to view the detailed reports and notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.
At the moment I stored the fuzzers in the Google OSS-Fuzz repository, but we can move them up here to make maintenance easier. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2660
-- Commit Summary --
* Adds initial fuzzer for integration with oss-fuzz.
-- File Changes --
A fuzz/fuzz_uri.c (8)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2660.patch https://github.com/kamailio/kamailio/pull/2660.diff
Thanks for working on this, definitely something interesting to have!
I have a few questions, to figure out what is the best way to integrate.
The patch shows that a new folder `fuzz/` in the root folder of kamailio source tree, with a new file `fuzz_uri.c` that has:
``` #include "../parser/parse_uri.c" ```
But the included file is at `../src/core/parser/parse_uri.c`. Is it part of the fuzzing platform/process to provide the path where to look for files to be included (e.g., to be set in some config or given as cli parameter)?
Does the `fuzz` folder have to be in the root folder of the project?
Then, I assume this is only the start, the patch looks like fuzzing for URI parser, I guess that similar files have to be added for other functions that we want fuzzing for, right?
You can see the `build.sh` scrip here https://github.com/google/oss-fuzz/pull/5279/files which is used to build the fuzzer. This may help clarify the structure of the set up.
We simple indicate where to find `parse_uri.c` by way of `-I`. Perhaps it would be smarter to change it to `#include "core/parser/parse_uri.c"`. In either case we can place the fuzzer wherever we like and I am happy to put it in the location that you prefer.
Yes, this is just the beginning and it would be great to add more. Similar files will have to be added for other parts of the code.
Great addition. I would suggest to add some #ifdef OSS_FUZZ around the fuzzing specific parts, which is deactivated by default. So we are not compiling it for everybody that do not need it.
@DavidKorczynski: a while ago we cleaned up the root folder, because it ended up with too many directories and files, therefore I would try to avoid starting adding there again. I would suggest to place it in `misc/fuzz`.
Then, the only other requirement is format the commit message according to the contributing guidelines:
* https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md#com...
I can merge this pull request manually (and place it in `misc/fuzz`), but have in mind the guidelines for future commits/pull requests, we use the git history to generate the changelogs for releases.
@miconda apologies for the delay in reply here. Putting the fuzzer in `misc/fuzz` works well for me, and if you can merge it in manually then that would be great - I will then handle all that is needed on the OSS-Fuzz side of things. Could you please also provide an email(s) that will get access to the data produced by OSS-Fuzz?
Closed #2660.
I merged manually the PR and created the email alias ossfuzz@kamailio.org that can be used for notifications -- we can divert it as we need in the future.
I added a README.md to collect information about fuzzing with OSS-Fuzz from kamailio point of view.
Let me know if you need anything else from infrastructure point of view as well as how we can help further to add more support for fuzzing.
Just a quick note on this one: the OSS-Fuzz PR has now been merged and fuzzing should start soon: https://github.com/google/oss-fuzz/pull/5279#event-4538430976
-
Daniel-Constantin Mierla -
DavidKorczynski
-
Henning Westerholt