cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Proposal: hooks support for plugins
Date Mon, 21 Apr 2014 20:08:40 GMT
Looks good Sergey, I like this approach.
I also agree with Parash's statements, I think we should consider plugin
hook sandboxing out of scope.

@purplecabbage
risingj.com


On Mon, Apr 21, 2014 at 12:39 PM, Sergey Grebnov (Akvelon) <
v-segreb@microsoft.com> wrote:

> Updated PR: https://github.com/apache/cordova-plugman/pull/74
>
> 1. Created issue CB-6481 to cover this work.
> 2. Switched to nodejs module loader. Sample hook file implementation with
> async functionality:
>
> var Q = require('./q');
>
> module.exports = function(platform, projectDir, pluginDir, cmdLine) {
>     console.log('hook.js: ' + platform);
>     console.log('hook.js: ' + projectDir);
>     console.log('hook.js: ' + pluginDir);
>     console.log('hook.js: ' + cmdLine);
>
>     var deferral = new Q.defer();
>
>     setTimeout(function(){
>         deferral.resolve();
>     }, 1000);
>
>     return deferral.promise;
> }
>
> Thx!!
> Sergey
>
> -----Original Message-----
> From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panarasi@microsoft.com]
> Sent: Friday, April 18, 2014 12:30 PM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: hooks support for plugins
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message