GumpacG opened a new pull request, #3578:
URL: https://github.com/apache/tinkerpop/pull/3578
## Summary
Several Gryo type registrations, mostly `TraversalStrategy` implementations
and `TraversalExplanation`,
were bound to Kryo's `JavaSerializer`, which deserializes via
`java.io.ObjectInputStream.readObject()`.
Reading a Gryo document from an untrusted source could therefore reconstruct
and run an arbitrary
`Serializable` object graph during decoding, before the graph layer accepts
or rejects anything.
This change stops the graph-document IO paths from reaching that sink, while
leaving full fidelity
available for trusted, in-process use.
## What changed
**New API**
- `GryoMapper.Builder.javaSerializationAllowed(boolean)`, default `true`.
When `false`, every registration
whose serializer resolves to a `JavaSerializer` is dropped, including
registrations contributed through an
`IoRegistry` or `addCustom(...)`, whether the serializer is supplied
directly, as a `Function`, or via a
class default serializer.
**Paths hardened (build their mappers with
`javaSerializationAllowed(false)`)**
- The `io()` step (read and write branches)
- `GryoReader` and `GryoWriter` default mappers
- `GryoIo` (covers `graph.io(IoCore.gryo())` and `gryo` graph persistence)
- The Hadoop Gryo input/output formats (`GryoRecordReader`,
`GryoRecordWriter`)
Reads and writes are hardened together so these paths cannot produce a
document they will not read back.
**Unchanged (full fidelity retained for trusted bytes)**
- A directly built `GryoMapper.build().create()`
- `GryoPool`, and the `spark-gremlin` and Hadoop object pools (which
additionally run unlocked by design)
- GraphSON and GraphBinary (never used native Java serialization)
## Behavior change
A stream that presents one of the affected type ids now fails with an
unregistered class id instead of
being deserialized:
```
org.apache.tinkerpop.shaded.kryo.KryoException: Encountered unregistered
class ID: 187
```
Affected types: `PartitionStrategy`, `SubgraphStrategy`, `SeedStrategy`,
`VertexProgramStrategy`,
`ProductiveByStrategy`, `OptionsStrategy` and `TraversalExplanation` in both
Gryo 1.0 and 3.0, plus
`GroupStep.GroupBiOperator` and `OrderGlobalStep.OrderBiOperator` in Gryo
1.0.
## Capability impact
A graph document produced by `writeGraph`/`writeVertices` contains only
vertices, edges, properties and
their values, never strategies, so in practice nothing is lost on the
graph-document paths. Nothing in the
repository round-trips these types through Gryo: OLAP ships strategies to
workers via JDK serialization in
the job configuration, not through the Gryo registrations.
The capability is removed from the default, not from the product. A directly
built mapper keeps full
fidelity, and `javaSerializationAllowed(true)` restores it on any builder.
`GryoIo` exposes it through the
`onMapper` consumer where the bytes are trusted:
```java
GryoIo.build().graph(graph).onMapper(m -> ((GryoMapper.Builder)
m).javaSerializationAllowed(true)).create();
```
Migration: a caller holding an older `.kryo` document that embeds one of the
affected types can read it by
supplying a mapper with `javaSerializationAllowed(true)` to `GryoReader`, or
via the `onMapper` hook above.
## Testing
- `GryoMapperTest` (parameterized over Gryo 1.0 and 3.0): a canary proving
`readObject()` does not run on a
hardened read, a positive control proving the crafted bytes do reach the
sink on a full-fidelity mapper
(so the negative assertions are meaningful), graph-structure round-trips,
and registration checks against
the constructed `Kryo` for default, direct-custom, `Function`-custom and
class-default-serializer forms.
- `GryoRecordReaderWriterTest`: asserts the Hadoop reader and writer build
hardened mappers.
## Docs
CHANGELOG entry, an upgrade note in
`docs/src/upgrade/release-3.7.x.asciidoc`, and scoped updates to
`THREAT_MODEL.md` (sections 8 and 9) describing which mappers are hardened.
Assisted-by: Kiro: Claude Opus 4.8
--
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]
