On Mon, Aug 11, 2014 at 5:26 AM, Andersson, Gunnar <gunnar.x.anders...@volvocars.com> wrote: > Everyone, > > Sorry for reacting to this so slowly. (Copying genivi-dev for info.) > > On 5 Aug 2014, at 07:53, Dominig ar Foll (Intel OTC) > <dominig.arf...@fridu.net> wrote: > >> Le 05/08/2014 00:58, Rees, Kevron a écrit : >>> On Mon, Aug 4, 2014 at 3:45 PM, Schaufler, Casey >> >>> <casey.schauf...@intel.com> wrote: >>> >>>> We should start looking at using Cynara for application >>>> (W3C) privilege enforcement. >>>> >>> I need to get with John to talk about whether Cynara would best be >>> used inside AMB or at the crosswalk-extension level. It's on my TODO >>> list. >>> >> >> It shall be done in AMB directly in order to allow non HTML5 Apps to benefit >> of the security. This is in particular critical when the socket transport >> mode is used as there is in that case no other security enforcement point. > > I'd just like to request the AMB project and other component developers to > consider not integrating too tightly with specific technologies. Having the > AMB tightly interact with Cynara might (depending on how you do it) > effectively > make it a Tizen-only component. > > Will you be able to do it in a generic and replaceable way? >
I completely agree. The plan is to make cynara integration a plugin that can be optionally built and optionally run. -Kevron > Dominig - discussing a pattern for adapting "generic" services to Tizen in a > non-intrusive way would be good, IMHO. Let me elaborate. > > Except from Tizen IVI, there might be no other GENIVI compliant platform that > uses Cynara, and I doubt that it will be possible to require it as the only > solution for service access policy enforcement. > > In this case I consider AMB to be a potentially generic component. AMB is a > project that has been followed by GENIVI since its inception and was proposed > by the Networking EG to be included into GENIVI compliance specification. (It > was withdrawn due to some technicalities, but that does not change the point > for the future; it is still usable in GENIVI systems). > > It's probably OK for the "special daemons" (as we called them in the > GENIVI/Tizen joint F2F; not sure if there is another name). They use a freely > defined communication over sockets, and are in their code project strongly > tied > to the corresponding Tizen Core API. Tight interaction with other Tizen-only > technologies should be fine there because those components are basically > Tizen-unique anyway. > > But as Tizen moves into implementing its security mechanism also for D-Bus and > integrating other generic services I would propose to also consider non-Tizen > systems. If we aim for a modular and generic approach for any generic > component > there is the potential for broader reuse. In particular the security > enforcement > mechanisms is an area with much variation in different distros, so keeping its > integration flexible would be good. > > Finally, this is probably a non-issue but just in case: for any component that > you *do* make such changes to I would like to remind everyone to be diligent > with popular versioning principles (likely best described by > http://semver.org/). > Those are also used in GENIVI. Specifically, if there is any incompatible API > change (which I suppose an enforced security policy is), then the major number > should be increased on the released version. This will match how GENIVI uses > version numbers in its specifications. It will avoid the risk of an already > released GENIVI spec (which frequently requires a component version N <= > [used-version] < N+1), to be after-the-fact matching what has later > become an incompatible component. > > Thanks for considering, > - Gunnar > > -- > Gunnar Andersson > Lead Architect, GENIVI Alliance > Infotainment, Volvo Car Corporation > >> >> Dominig >> _______________________________________________ >> IVI mailing list >> IVI@lists.tizen.org >> https://lists.tizen.org/listinfo/ivi >> _______________________________________________ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
