[
https://issues.apache.org/jira/browse/PROTON-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105589#comment-18105589
]
ASF GitHub Bot commented on PROTON-2957:
----------------------------------------
jiridanek opened a new pull request, #450:
URL: https://github.com/apache/qpid-proton/pull/450
https://issues.apache.org/jira/browse/PROTON-2957
`pn_message_decode()` only scans the wire-level section framing (header,
properties, annotations, application-properties, body) and stores each
section's raw, undecoded bytes on the `pn_message_t`. It never invokes the
generic AMQP codec (`codec.c`, `decoder.c`) on any of that content
> fuzz-message-decode harness doesn't exercise the codec on decoded message
> content
> ---------------------------------------------------------------------------------
>
> Key: PROTON-2957
> URL: https://issues.apache.org/jira/browse/PROTON-2957
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Reporter: Jiri Daněk
> Priority: Major
>
> {{pn_message_decode()}} only scans the wire-level section framing (header,
> properties, delivery-annotations, message-annotations,
> application-properties, body) and stores each section's raw, undecoded bytes
> on the {{pn_message_t}}. It never invokes the generic AMQP codec
> ({{codec.c}}, {{decoder.c}}) on any of that content -- that only happens
> lazily, the first time an application calls one of the
> {{pn_message_instructions()}}, {{pn_message_annotations()}},
> {{pn_message_properties()}}, or {{pn_message_body()}} accessors.
> The fuzz-message-decode harness ({{c/tests/fuzz/fuzz-message-decode.c}}) only
> ever calls {{pn_message_decode()}} and discards the result, so none of those
> accessors are ever invoked and the fuzzer's input never actually reaches the
> codec, despite fuzz-message-decode being one of only two targets with
> continuous OSS-Fuzz history.
> Proposed fix: call the four accessors above and force a full read-side
> traversal of each resulting {{pn_data_t}} via {{pn_data_format()}}, then
> round-trip the message back to bytes via {{pn_message_encode2()}} to also
> exercise the encoder on the same content. This implements the harness's own
> long-standing "FUTURE: do something like encode msg and compare again with
> Data" comment.
> I'll attach a PR with this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
