On Wednesday 25 March 2009 09:36:50 Fabrizio Montesi wrote: > On Wed, Mar 25, 2009 at 9:24 AM, Kevin Ottens <er...@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
