[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: GSoC proposal draft: network transparency.
From:       Rob Scheepmaker <r.scheepmaker () student ! utwente ! nl>
Date:       2009-03-27 15:22:22
Message-ID: 200903271622.22843.r.scheepmaker () student ! utwente ! nl
[Download RAW message or body]

On Wednesday 25 March 2009 09:36:50 Fabrizio Montesi wrote:
> On Wed, Mar 25, 2009 at 9:24 AM, Kevin Ottens <ervin@kde.org> wrote:
> > Keep in mind that right now I'm concentrating on the "using services"
> > part of
> > the library. I'm somehow "forced" to put the "exposing services" part on
> > hold
> > because I'm waiting on some changes on Jolie's Metaservice side. AFAIK
> > Fabrizio is working on that, but I don't really know when that'll
> > deliver.
>
> At italianaSoftware we just finished the design of a feature I was waiting
> for which should solve all our problems w.r.t. security and service
> exposure.
> So the ETA is "not too far away". ;)

Excellent. :) I understand that you don't want to promise anything but do you 
have a more specific ETA? ;) The first part of SoC is still only API design and 
stuff like that, so I don't need an implementation immediately when soc starts, 
as long as you have at least a document describing the basic design.

> > > The security implications will need to be thought trough. We will need
> >
> > some
> >
> > > some way of authenticating systems that are allowed access to published
> > > applets or activities.
> >
> > Oh, and once the library is ready to expose services, it's likely that
> > for the
> > first iteration it'll be a huge security hole. Jolie won't yet provide
> > the security model, which means you'll be left on your own to
> > authenticate clients. OTOH once Jolie provides a security model it won't
> > be necessary for
> > you to deal with that anymore (or at least it'll be much less
> > complicated).
>
> The new feature I'm gonna put in Jolie should make it easy to "inject"
> security into unsecure services. We would still need to think the security
> model we want in our particular case (Plasma+Jolie). There are various
> possibilities, and the user should be prompted by Plasma when necessary.
> The sooner we start thinking about this, the better.

I'm really interested in that security feature in JOLIE. Is there anywhere I 
can read something about it? some blog post or design document?
Anyway, I guess we'll want to provide different ways of authentication in the 
plasma+jollie case, depending on what kind of situation the network 
transparency is used for:

For Alice's use case, a white list of ip addresses that are allowed to access 
shared applets, activities, dataengines and services makes sense. For Bob's 
and Charlie's cases: either some username+password authentication or simply 
asking permission on the PC that shares the activities once it gets accessed 
would work best.

Also, we should consider that sharing a activity/applet is considerably more 
'dangerous' then copying. The user should be able to specify security policy 
for both cases. For copying some users might even want no security.

> > > Timeline
> > > April 20 – May 22: Community bonding period, experiment with Kevin's
> > > library, draft and discuss the required api. Draft and discuss the
> > > interfaces for the required services.
> >
> > Hmmm, April 20, I'll seriously have to move faster, and kick Fabrizio
> > harder.
> > ;-)
>
> My god, we will have to write some documentation! ;-)

Yes you do ;)

> > I'm seriously looking forward to your work. Obviously when the time comes
> > I'm
> > willing to mentor or co-mentor you. So far it's been always a pleasure to
> > work
> > with you, I'd be a fool not to participate in your mentoring. :-)
>
> I'm interesting in helping co-mentoring this, too. This will really put the
> qt/jolie integration to work.

Thanks,  I'd love working with you both on making network transparency in 
plasma rock. Thanks for the feedback. :)

Regards,
Rob
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[prev in list] [next in list] [prev in thread] [next in thread]