Akanksha-kedia commented on PR #6760:
URL: https://github.com/apache/hive/pull/6760#issuecomment-5633074443
@ayushtkn — what introduced this: Avro 1.12.x added
`org.apache.avro.util.ClassSecurityValidator`, which as of 1.12.2 rejects
resolving any class as `SpecificRecord` unless explicitly trusted via
`org.apache.avro.SERIALIZABLE_CLASSES`/`SERIALIZABLE_PACKAGES`.
`AvroBytesConverterTest` hits this because `KafkaAvroSerializer.serialize()`
builds a `SpecificDatumWriter`, which resolves the test's `SimpleRecord`
fixture — now forbidden by default.
Reproduced locally just now: reverting the `maven-surefire-plugin`
`systemPropertyVariables` change and rerunning `AvroBytesConverterTest` fails
deterministically with:
```
java.lang.SecurityException: Forbidden
org.apache.hadoop.hive.kafka.SimpleRecord! This class is not trusted...
at org.apache.avro.specific.SpecificDatumWriter.<init>
at io.confluent.kafka.serializers.AbstractKafkaAvroSerializer.serializeImpl
```
With the property restored, `mvn -pl kafka-handler test
-Dtest=AvroBytesConverterTest` passes 5/5.
To your point — this is **not just a test-only fix**.
`KafkaSerDe.AvroBytesConverter.getWritable()` (production deserialization path)
builds a `SpecificDatumReader`, which goes through the identical
`SpecificData.getClass()` check. So any real user querying Kafka Avro data via
Confluent Schema Registry + code-generated `SpecificRecord` classes will hit
the same `SecurityException` at runtime after this bump — the test just happens
to be the thing that caught it in CI. I didn't add a production-side trust
workaround because picking that trust boundary (e.g. blanket-trusting a
package) is a real security decision that risks reintroducing the CVE this Avro
change closes, and affects arbitrary user class names — not something to decide
unilaterally in a version-bump PR. Wanted your take on whether this needs a
Hive-side default-trust mechanism, a migration note, or should block until
resolved.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
