[MISC] initial Genesis Fuzz Support fuzz_target.py
Introducing foundational fuzzing support for Genesis to help identify and resolve potential issues.
Once merged, I will submit a pull request to the OSS-Fuzz repo to enable fuzzing for this library on Google infrastructure. Any identified bugs will be reported to the Genesis maintainers.
Kindly review the OSS-Fuzz documentation and Bug Disclosure Guidelines before proceeding with the merge.
Thanks
Hii @YilingQiao Could Team Review This PR as well as can I get maintainer list so I can Add them who get notified above Alerts
Thanks
Hi Shivam,
Thank you for your PR. I’m not sure if we need this workflow at the moment. Are there other similar repositories using it? Our current priority is to address some urgent bugs. Let me discuss this with others and get back to you. Thank you so much for your time!
Hii @YilingQiao Okay Thanks For Response Yes You can discuss and let me know also I had created Above Fuzz Target py file also Ultimately it will Improves the System and Get Alerts as you will Review Documentation of it Here are list of Project which is aling with ossfuzz https://github.com/google/oss-fuzz/tree/master/projects Thanks again
Introducing foundational fuzzing support for Genesis to help identify and resolve potential issues.
Once merged, I will submit a pull request to the OSS-Fuzz repo to enable fuzzing for this library on Google infrastructure. Any identified bugs will be reported to the Genesis maintainers.
Kindly review the OSS-Fuzz documentation and Bug Disclosure Guidelines before proceeding with the merge.
Thanks
Hii @YilingQiao @zhouxian Can I Proceed with this? If yes Could Team please Merge This PR to this Repo Thanks
Reminder Hii @ziyanx02 @YilingQiao @zhouxian Can I Proceed with this? If yes Could Team please Merge This PR to this Repo So then I will make PR in ossfuzz to integrate Project Thanks
Hi, @Shivam7-1 , can you elaborate further on why this is needed and why it is not yet a common practice for similar repositories (such as MuJoCo and Bullet3)? We are not entirely sure about the pros and cons of this additional workflow.
Hii @YilingQiao @Kashu7100 @ziyanx02 Thanks For Response The initial fuzz integration file is useful to ensure that we can identify potential issues early in the development process
-
Automated Testing and Early Bug Detection: Fuzz testing automatically generates random, invalid, or unexpected inputs to test the system’s resilience. By integrating fuzzing into the project early, we can identify edge cases, vulnerabilities, and crashes that might otherwise be missed during manual testing. This significantly enhances the robustness of the system.
-
Improving Code Quality: Fuzz testing helps detect flaws that could lead to security vulnerabilities, performance bottlenecks, or unexpected behavior. Integrating this into the Genesis project from the outset allows us to maintain high-quality, stable, and secure code as we move forward.
-
Efficiency: Implementing fuzz testing early in the process can save both time and resources. Catching issues early in the development lifecycle helps avoid the higher costs of fixing bugs later in the process, especially when the system is more complex and harder to change.
For similiar Repo I am unaware about this but I think this would be better here to use or any project Further you can also look into this OSS-Fuzz documentation and Bug Disclosure Guidelines
The PR code seems not providing valuable check at this moment to me. I don't see any benefit of including this at this point.
Hii @Kashu7100 Thanks For Reviewing What things Could make this more better check and can be added?
First of all, what do you want to check with fuzzing (in your PR for example)? The purpose or intention is very unclear, which makes unlikely to be merged. Second, we currently have the automated workflow for basic check. You haven't provided any merit of using this fuzzer over the current workflow that we have. Also you didn't give clear reason why similar projects such as MuJoCo and Bullet3 are not adapting your suggested workflow (I guess there's no need for fuzzing).
If you still want to convince us, could you update your PR to include the code that you think is actually beneficial for Genesis debugging?