Akanksha-kedia commented on code in PR #6760:
URL: https://github.com/apache/hive/pull/6760#discussion_r3988983818
##########
kafka-handler/pom.xml:
##########
@@ -227,6 +227,20 @@
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
</plugin>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-surefire-plugin</artifactId>
+ <configuration>
+ <!-- Avro's ClassSecurityValidator reads the trusted-classes
allowlist once when it is
+ first loaded, so it must be present as a JVM system property
from fork startup;
+ setting it at test runtime (e.g. in @BeforeClass) is too late.
Scoped to this
+ module's own SimpleRecord test fixture (used by
AvroBytesConverterTest), not a
+ repo-wide trust grant. -->
+ <systemPropertyVariables>
+
<org.apache.avro.SERIALIZABLE_CLASSES>org.apache.hadoop.hive.kafka.SimpleRecord</org.apache.avro.SERIALIZABLE_CLASSES>
+ </systemPropertyVariables>
+ </configuration>
Review Comment:
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 this test's `SimpleRecord`
fixture — now forbidden by default.
Reproduced locally: reverting this `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 it restored, `mvn -pl kafka-handler test -Dtest=AvroBytesConverterTest`
passes 5/5.
To your "test-only" question — it's not.
`KafkaSerDe.AvroBytesConverter.getWritable()` (the production deserialization
path) builds a `SpecificDatumReader`, going through the identical
`SpecificData.getClass()` check. 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 — this test just
happens to be what caught it in CI. I didn't add a production-side trust
workaround because picking that trust boundary is a real security decision
(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]
