cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram Narasimhan (MS OPEN TECH)" <panar...@microsoft.com>
Subject RE: Proposal: hooks support for plugins
Date Fri, 18 Apr 2014 19:29:57 GMT
As you rightly pointed out, this proposal is very similar to npm modules, where modules get
full access as the hosting code. IMHO, the problem of sandboxing may not be specific to Cordova
and I am not sure if we could solve it for the Cordova/Plugman CLI without creating an really
complex system. For example, we may not have to stop just with Sandboxing files, we would
even want to sandbox sockets, child_process and other core node capabilities as well. 
If we do create such a sandbox model, should it not be a separate system that can be used
by other "module-loaders" as well? CordovaCLI can be yet another consumer of this sandbox.


-----Original Message-----
From: Shazron [mailto:shazron@gmail.com] 
Sent: Friday, April 18, 2014 11:16 AM
To: dev@cordova.apache.org
Subject: Re: Proposal: hooks support for plugins

Sorry for the flurry of emails, found a proof of concept for overriding the filesystem core
api, using nodejs vm:
https://github.com/augustl/nodejs-sandboxed-fs


On Fri, Apr 18, 2014 at 11:00 AM, Shazron <shazron@gmail.com> wrote:

> Just food for thought for the future, regarding trust for these 
> scripts, based on the discussion so far:
>
> 1. Security model is basically what npm's security model for scripts 
> are (full trust) 2. We could manually "verify" the scripts (for each 
> update! gets tedious), but before it is verified, there is a banner in 
> the plugin registry. Not sure how this works with command line adding 
> of plugins with scripts, and dependencies, since users will not see 
> that banner, and if we have a text warning with confirmation, that 
> gets annoying.
> 3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure 
> exactly how (haven't investigated fully).
>
> I think the ideal situation is to:
> 1. sandbox filesystem reads to the project folder only 2. sandbox 
> filesystem writes to the project folder only 3. prevent the plugin 
> from executing scripts that either exist or are have been created in 
> the project folder
>
> Not sure how to do this yet though (how to override the node 
> filesystem core api temporarily).
>
>
>
>
> On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b@brian.io> wrote:
>
>> yes! (ideally we kill magic folders and make this explicit in the 
>> config)
>>
>>
>> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) < 
>> v-segreb@microsoft.com> wrote:
>>
>> > Sound like most of us prefer module.export.  Cool, will update the 
>> > code today and let you know once this is done.
>> >
>> > Since we will be moving to cordova-lib the next action item here 
>> > could
>> be
>> > creating uniform hooks with shared code for both application level 
>> > and plugin level hooks. Thoughts?
>> >
>> > Thx!
>> > Sergey
>> > -----Original Message-----
>> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On 
>> > Behalf
>> Of
>> > Brian LeRoux
>> > Sent: Friday, April 18, 2014 8:25 AM
>> > To: dev@cordova.apache.org
>> > Subject: Re: Proposal: hooks support for plugins
>> >
>> > like this too / would be much cleaner
>> >
>> >
>> >
>> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <shazron@gmail.com> wrote:
>> >
>> > > I like Parashuram's idea. This way the plugin hooks can be 
>> > > testable as well?
>> > >
>> > >
>> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN 
>> > > TECH) < panarasi@microsoft.com> wrote:
>> > >
>> > > > Currently, the plugin hooks are constructed like the hooks in a 
>> > > > cordova project. An alternative would be to construct the 
>> > > > javascript files to
>> > > have
>> > > > module.exports, and we could pass in the parameters to the 
>> > > > function that
>> > > is
>> > > > exported. This way, the module will not spawn a new node process.
>> > > > Comments, Thoughts?
>> > > >
>> > > > -----Original Message-----
>> > > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
>> > > > Sent: Thursday, April 17, 2014 5:19 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > I've sent a pull request with initial implementation for review.
>> > > > https://github.com/apache/cordova-plugman/pull/74
>> > > >
>> > > > Thx!
>> > > > Sergey
>> > > > -----Original Message-----
>> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
>> > > > Sent: Thursday, March 6, 2014 2:07 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
>> > > > > Can we think about scripts as just a new plugin module?  - 
>> > > > > Similar to js-module or config-file and which must be 
>> > > > > processed special way (by execution).
>> > > > >
>> > > > > <script-module src="src/compile_sqlite.js"/> <framework

>> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> 
>> > > > > <script-module src="src/add_win8_toastCapable.js"/>
>> > > > > <script-module src="src/set_default_target_paltform_arm.js"/>
>> > > > >
>> > > > > Not so powerful and cool, but easy to implement and understand.
>> > > > > During uninstall each script is called again but with 'uninstall'
>> > > > > flag (or each script file can emit install and uninstall
>> > > > > functions)
>> > > > >
>> > > >
>> > > > I'm all for simple, what happens if one of those scripts fails? E.g.
>> > > > failed compile
>> > > >
>> > > > For example in cli:
>> > > >
>> > > > cordova plugin add sqlite
>> > > > platforms = ['android', 'windows8']; for(p in platforms)
>> > > >     installPlugin('sqlite');  // android ok! windows8 fails at 
>> > > > 'src/compile_sqlite.js'
>> > > >
>> > > > Is 'sqlite' at that point installed on android? Do we rollback 
>> > > > the install? Run the uninstall() scripts?
>> > > >
>> > > > For that reason, sandbox idea seems less chaotic with some 
>> > > > hookApi -
>> > > which
>> > > > would cleanup properly if something goes wrong...
>> > > >
>> > > > What you're suggesting seems like it could work, until 
>> > > > something goes wrong and leaves the platform(s) project/native 
>> > > > in an
>> > inconsistent state.
>> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
>> > > >
>> > > > Could be doable but not sure well it would work.
>> > > >
>> > > >
>> > >
>> >
>>
>
>
Mime
View raw message