paulk-asert opened a new pull request, #2805:
URL: https://github.com/apache/groovy/pull/2805
The class-loader-aware newObjectInputStream overrode resolveClass with
Class.forName(desc.getName(), true, classLoader)
where ObjectInputStream's own resolveClass passes false. Pass false too.
History: the override was written in af544cb4a (2008-12-05) for GROOVY-1627,
"Deserialization fails to work", and has never been changed since; the 2012
extraction of IOGroovyMethods out of DefaultGroovyMethods (f0ca6893a) only
moved it. The initialize flag looks incidental rather than chosen. The same
2008 commit added newObjectInputStream(InputStream) with no override at all,
which therefore defers initialization the way the JDK does, so the two siblings
disagreed from the day they were written; and the problem being solved was
which loader can see a script-defined class, not whether that class should be
initialized. The accompanying test, StreamClassloaderInScriptTest, passes
either way.
Effect: a class named in a stream that then fails to deserialize no longer
has its static initializer run. The window is narrow but reachable by anyone
who controls the stream, since resolveClass runs before the local class
descriptor is looked up: a stream truncated between those two points
initializes the named class under true and does not under false. Once the local
descriptor is looked up the class may initialize regardless, because reading a
declared serialVersionUID field initializes it, and a stream that deserializes
successfully initializes the class when the instance is created. No legitimate
stream can observe the difference.
No test accompanies this. Reaching the window requires failing between
resolveClass and the descriptor lookup, which is only expressible as a
byte-offset truncation of a serialized stream and would be brittle; an attempt
using a serialVersionUID mismatch to fail deterministically was discarded
because reading that field initializes the class by itself and so cannot
distinguish the two settings.
--
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]
