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-seg...@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:panar...@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:shaz...@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 <shaz...@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-seg...@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.ler...@gmail.com [mailto:brian.ler...@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 <shaz...@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) < panar...@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-seg...@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:jbo...@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. > >> > > > > >> > > > > >> > > > >> > > >> > > > > >
