Re: [rt-pmc] ECF 3.12.0

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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