> On May 22, 2020, at 10:52 AM, Sijie Guo <guosi...@gmail.com> wrote:
>
> Hi all,
>
> I would like to kick off a discussion about what we should do for protobuf
> 2.4.1 and figure out what is the long term plan.
>
> Currently, Pulsar is using a customized version of protobuf 2.4.1 for wire
> protocol. The customization was made to leverage netty object pooling to
> reduce object generation and cause bad JVM GC behavior. However, protobuf
> 2.4.1 is a many-years old release and there is also a vulnerability issue
> reported for protobuf-java 2.4.1 (
> https://nvd.nist.gov/vuln/detail/CVE-2015-5237). We need to figure out a
> plan to upgrade this dependency.
>
> Here are some thoughts. Happy to see what others think.
>
> a) We upgrade to protobuf 3.x without customization.
>
> - Pros: be able to catch up with changes in protobuf and avoid any
> vulnerabilities.
> - Cons: we might have to suffer the pains from object generations. But it
> might not be too bad since we don't store the message payloads in protobuf.
>
> b) We upgrade to protobuf 3.x with new customization.
>
> - Pros: We are able to control object generations.
> - Cons: Maintaining a customization makes harder to catch up changes in
> protobuf community and avoid vulnerabilities.
Is it possible that the protobuf community would want us to upstream the
customizations?
Regards,
Dave
>
> c) Look for other alternatives to protobuf such as flatbuffers.
>
> - Cons: it is not a backward-compatible solution with existing Pulsar
> clients.
>
> - Sijie
