[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
On 11/18/2015 11:18 PM, Christian Campo wrote:
+1
Just out of curiosity. Is ECF affected by the commons collections problem
?
We don't have any dependencies on commons collections in our code. But
there are occasions where object serialization is used within individual
distribution providers (e.g. rosgi, jms, jax-rs, hazelcast, mqtt,
perhaps other providers).
Does it contain a deserializer mechanism that deserializes generic
objects and calls the readObject method like java serialization or hessian
serialization ?
Yes there are plenty of occasions where objects are deserialized, again
specific to the distribution provider.
To provide OSGi-spec compliant remote services, one essentially has to
trust the distribution provider implementation since it controls both
the object serialization/deserialization as well as transport/wire
protocol.
The distribution providers that ECF has implemented generally have an
authentication/credentials checking step so that more trust can be
established at runtime if desired (e.g. ssl client auth). None of the
distribution providers that I'm aware of expose any API like the
collections InvokerTransformer, although several of them are extensible,
and so allow the creation of new providers that substitute/replace the
object serialization and/or replace the wire protocol (e.g. JMS).
However, since there are distribution providers not created by us, and
we are trying to make the creation of such providers easier to allow
alternative serialization and comm protocols [1], it would be possible
for people to create providers that do 'nasty things' during/as a part
of RS distribution.
One way to look at it: since with OSGi RS/RSA the distribution provider
is implemented *once* (instead of separately for each remote service),
it's a somewhat better situation than having individual distribution
systems for every remote service (as is true without OSGi RS). Also,
the OSGi spec does allow the easy switching of distribution providers
(no service-level changes), and so if exploits are found in an
individual provider it can be replaced at runtime without rewriting the
remote service impl or consumer. IMHO this is a big advantage of the
OSGi Remote Services/OSGi Service Registry abstractions.
My $0.03.
Scott
[1]
https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services
Just wondering
christian
Am 18.11.15, 20:47 schrieb "rt-pmc-bounces@xxxxxxxxxxx on behalf of Scott
Lewis" unter <rt-pmc-bounces@xxxxxxxxxxx on behalf of
slewis@xxxxxxxxxxxxx>:
Greets,
ECF would like to have a minor release on Nov 30 [1].
This release is focused on adding to and improving the Remote
Services/RSA Tooling first introduced prior to Mars [2]. It does,
however, include new UI APIs to allow Eclipse-based RS/RSA tooling to be
created more easily by us an others, thus the need for a minor rather
than maintenance release.
No incompatible API changes. No feature-level changes to OSGi
spec-compliant impl of RS/RSA...only a few minor bug fixes there.
Please approve this release.
Scott
[1] https://projects.eclipse.org/projects/rt.ecf/releases/3.12.0
[2] https://www.eclipse.org/ecf/NewAndNoteworthy_3.10.0.html
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
https://dev.eclipse.org/mailman/listinfo/rt-pmc
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/rt-pmc