I think I’m repeating what Christian said….
Deseriailizing arbitrary classes usually results in a giant security exposure,
as there are exploits that result in arbitrary code execution on
deserialization (not use!) of some commonly used library class instances. Most
of the projects I’m involve
I think you should not use any magic for calls that need classloading using
a class named by a string (Like in deserialization). The only safe way is
to explicitly specify a classloader to use.
Christian
2016-10-27 15:11 GMT+02:00 Christopher BROWN :
> Hi Scott, Hi Carsten,
>
> Overridding Objec
Hi Scott, Hi Carsten,
Overridding ObjectInputStream::resolveClass was what I needed. My
"fetch" method has 3 variants:
/* uses Thread::getContextClassLoader */
Object fetch(String id)
/* uses type.getClass().getClassLoader(), may not work if "type" is an
interface or superclass, mainly useful f
Another (somewhat similar to Carsten's) approach to this is the one that
we've implemented in ECF's Remote Services/RSA implementation [1].
We've got a service interface: IClassResolver [2] and a
ObjectInputStream subclass called ClassResolverObjectInputStream. The
way that this works is that
Christopher Brown wrote
> Hello,
>
> I need to define an API for an OSGi service capable of persisting arbitrary
> Serializable objects as byte arrays (to disk, or over the network), and
> then capable of deserializing the object via the API. The objects to be
> persisted will almost always be de
5 matches
Mail list logo
