[jira] [Commented] (CALCITE-7436) Add high-coverage Jazzer fuzzing for Avatica core modules

["Mihai Budiu (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-7436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18066242#comment-18066242 ] 

Mihai Budiu commented on CALCITE-7436:
--------------------------------------

When does the fuzzer run? Is it run as part of CI? Is it a regular test?

> Add high-coverage Jazzer fuzzing for Avatica core modules
> ---------------------------------------------------------
>
>                 Key: CALCITE-7436
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7436
>             Project: Calcite
>          Issue Type: Improvement
>          Components: avatica
>            Reporter: Vishal Satish
>            Assignee: Vishal Satish
>            Priority: Major
>              Labels: pull-request-available
>
> [PR Link|https://github.com/apache/calcite-avatica/pull/300]
> Right now, the OSS-Fuzz setup for Avatica barely touches any of the important parts. I've checked the coverage on the core module and it is is basically zero because it only exercises a few peripheral helper classes.
> But by adding four proper "deep" fuzz targets using Jazzer (the libFuzzer-style fuzzer that works great with JVM projects). These targets will  live right inside the calcite-avatica module and are designed to fuzz the parts that actually matter for stability and security.{_}The new fuzzers covers the following{_}
>  * *JsonHandlerFuzzer* → stresses the full round-trip JSON serialization + deserialization of requests and responses (via Jackson)
>  * *ProtobufHandlerFuzzer* → checks binary parsing + POJO mapping for the Protobuf path — making sure nothing breaks when translating between wire format and Java objects
>  * *TypedValueFuzzer* → goes after the TypedValue factory and all the JDBC type conversions — especially fun things like numeric overflows, weird edge values, etc.
>  * *AvaticaSiteFuzzer* → uses dynamic proxies to exercise the JDBC-to-Java type translation logic across 15+ different SQL/JDBC types
>  * *Base64Fuzzer:* Protocol utility testing
>  * *ConnectStringParserFuzzer:* JDBC connection string parsing
> These are built to run on google's oss fuzz infrastructure, and if this issue gets rectified, we can push a pr to the google oss fuzz repo as well. 
> For now i have raised a pr in the calcita avatica repo : [PR Link|
> We've added a 'cifuzz.yml' GitHub Action to run these targets on every PR. These will pass once the Google OSS-Fuzz configuration is updated to reference this upstream source.
> [https://github.com/apache/calcite-avatica/pull/300]
>  
> I have also prepared a corresponding pr to the google oss fuzz repo [https://github.com/google/oss-fuzz/pull/15131]
> Once these targets are merged upstream, the OSS-Fuzz infrastructure will immediately begin running them 24/7 directly from the Apache source, ensuring continuous security and stability testing.
> The main things we're hoping to find and maybe we can fix as well.
>  * Out-of-memory crashes or crazy CPU usage
>  * Sneaky unchecked exceptions (BufferUnderflowException, etc.)
>  * Subtle bugs in how data gets translated between formats
> For local development, anyone can run these fuzzers quickly using the Jazzer CLI or the Maven plugin(Note: we've kept them out of regular JUnit CI on purpose as they're non-deterministic and eat a lot of CPU, so they're better suited for dedicated fuzzing environments.)
> Overall the fuzzers hit thousands of lines of code and it will significantly increase coverage of the fuzzers. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)