[
https://issues.apache.org/jira/browse/AVRO-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699426#comment-16699426
]
Evan McQuinn commented on AVRO-2250:
------------------------------------
Right, the commit we're really interested in is this one that Daniel made a
couple weeks ago:
[https://github.com/apache/avro/commit/c78a3d5ea4e7e511ba9f6182157956db3e65e1a0]
Unfortunately, because the guava dependency is shaded directly into the 1.8.2
jar, we can't remove the vulnerability from the classpath without doing
something like repackaging your jar or compiling a new one from source. Of
course doing so would mean upgrading guava from 11.0.2 (February 2012) to
24.1.1 (April 2018) which doesn't necessarily feel like a good idea either...
though I'd be curious to hear your thoughts on that.
If our timelines don't turn out to line up, another approach would be to
justify an exception. The vulnerability has to do with deserializing
AtomicDoubleArrays provided by a user (the fix is
[here|https://github.com/google/guava/commit/7ec8718f1e6e2814dabaa4b9f96b6b33a813101c]).
Because of the way we're using avro specifically (serialization in Kafka
topics w/ schemas stored in Confluent's schema registry) we can probably argue
that it would never happen, but is that class one that avro leverages at all in
the first place?
Anyway, just trying to think through approaches we could take. Thanks again!
> Release 1.9.0
> -------------
>
> Key: AVRO-2250
> URL: https://issues.apache.org/jira/browse/AVRO-2250
> Project: Apache Avro
> Issue Type: Task
> Reporter: Nandor Kollar
> Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
