gnodet commented on code in PR #25378: URL: https://github.com/apache/camel/pull/25378#discussion_r3728998310
########## core/camel-support/src/test/java/org/apache/camel/support/CamelObjectInputStreamTest.java: ########## @@ -0,0 +1,78 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.camel.support; + +import java.io.ByteArrayInputStream; +import java.io.ByteArrayOutputStream; +import java.io.IOException; +import java.io.InvalidClassException; +import java.io.ObjectOutputStream; +import java.net.InetSocketAddress; + +import org.junit.jupiter.api.Test; + +import static org.junit.jupiter.api.Assertions.assertEquals; +import static org.junit.jupiter.api.Assertions.assertThrows; Review Comment: Nit: the project convention prefers AssertJ assertions (`assertThat(...)`) for new test code. Not blocking — the sibling `DeserializationFilterHelperTest` also uses JUnit assertions, so this is consistent with the existing pattern in this area. ########## docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc: ########## @@ -55,6 +55,21 @@ recipient; aligning it with `toD` / `enrich` is deferred to a follow-up. If you need a placeholder resolved by `toD` / `enrich`, keep it in the route's endpoint URI rather than in the message. +=== camel-support - CamelObjectInputStream applies a deserialization filter by default + +`CamelObjectInputStream` (the shared stream used by Camel's Java-object deserialization paths, such +as the HTTP components) now installs a JEP-290 `java.io.ObjectInputFilter` while reading, as a +defense-in-depth measure against unsafe deserialization. When no explicit filter pattern is +supplied, the JVM-wide `jdk.serialFilter` is honoured if set, otherwise Camel's default allow-list +(`DeserializationFilterHelper.DEFAULT_DESERIALIZATION_FILTER`) is applied, which permits standard +Java and Apache Camel types, denies `java.net.**`, and enforces graph-shape limits. + +The built-in HTTP deserialization path already applied this filter, so most users are unaffected. +Code that constructs `CamelObjectInputStream` directly and deserializes types outside the default +allow-list must pass an explicit filter pattern to the new +`CamelObjectInputStream(InputStream, CamelContext, String)` constructor (or configure +`jdk.serialFilter`) to permit them. Review Comment: Minor documentation gap: since the 2-arg constructor now delegates to the 3-arg with `null` (which always installs a filter), any downstream code that previously called `setObjectInputFilter()` after constructing via the 2-arg constructor will get an `IllegalStateException` on JDK 17+ ("filter can not be set more than once"). Within Camel only `HttpHelper` used this class (and the PR correctly updates it), so the practical risk is low — but it might be worth adding a sentence here noting this backward-compatibility change and recommending the 3-arg constructor as the migration path for anyone who was calling `setObjectInputFilter()` directly. -- 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]
