You can also run arbitrary scripts via the <engine> tag. (you can specify your own script in it).
On Tue, Feb 10, 2015 at 12:22 PM, Horn, Julian C <julian.c.h...@intel.com> wrote: > Actually I see it the other way around. If you want to trust a plugin, > you can make that decision; it's your machine. The build server doesn’t > trust the plugins you trust. > > -----Original Message----- > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal > Mocny > Sent: Tuesday, February 10, 2015 11:27 AM > To: Michal Mocny > Cc: dev > Subject: Re: Plugin Install Hooks > > ..Not to mention, these plugins will be running on end users' personal > devices. That sounds vastly more concerning than running hooks on a server > you control and can sandbox. > > On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny <mmo...@chromium.org> > wrote: > > > So, I think this is not different than downloading and running > > packages from any package manager. > > > > That said, I think a --suppress-hooks flag would be fine. I suggest > > you file a JIRA so others can chime in, and if you want it to land > > soon I would take a stab at a PR. > > > > -Michal > > > > On Tue, Feb 10, 2015 at 10:02 AM, Horn, Julian C > > <julian.c.h...@intel.com> > > wrote: > > > >> Thanks for the pointer Shazron. I read through all of this > >> interesting discussion. I agree that sandboxing is hard and prompting > is problematic. > >> But there's still an issue here. > >> > >> If there is no mechanism to exclude scripting in untrusted plugins > >> then build servers are unlikely to accept any uncurated plugin, which > >> is what PGBuild is doing. The Intel XDK provides a build server. We > >> would like to support arbitrary third party plugins, not just ones we > >> have curated. This install-time hooks feature creates a major > >> security issue for us. Under no circumstances are we going to allow > >> untrusted native code to run on our build server. > >> > >> And thanks to Sergey for pointing out that issue with pre_package hooks! > >> We were under the impression that project-level hooks could be > >> suppressed by excluding the hooks directory. I see now that this isn't > sufficient. > >> > >> I have a very simple suggestion: add a "--suppress-hooks" flag. This > >> doesn't prompt: it assumes the answer to the prompt is "no". > >> > >> I don't have enough experience with install hooks to know if the > >> plugin is likely to be usable without running the install-time hook. > >> I expect that if you add a plugin that contains an install time hook > >> and --suppress-hooks is present, then the plugin add should fail. If > >> there's some reason to believe that a plugin could be usable without > >> running the install time hook, then maybe it would be interesting to > >> have a variant of --suppress-hooks that bypasses the hook but allows > >> the plugin to be installed anyway. > >> > >> I would also expect that --suppress-hooks would suppress pre_package > >> time hooks too. > >> > >> Julian > >> > >> -----Original Message----- > >> From: Shazron [mailto:shaz...@gmail.com] > >> Sent: Monday, February 09, 2015 4:21 PM > >> To: dev@cordova.apache.org > >> Subject: Re: Plugin Install Hooks > >> > >> We did discuss this, and we rejected: > >> 1. Having a prompt > >> 2. Sandboxing > >> > >> Check out the discussion, for reasons: > >> http://markmail.org/message/alknczhqdghaurrw > >> > >> On Mon, Feb 9, 2015 at 8:28 AM, Horn, Julian C > >> <julian.c.h...@intel.com> > >> wrote: > >> > We have identified a security issue with the recently added feature > >> > of > >> install-time plugin hooks. > >> > > >> > As far as I can tell, there is nothing that prevents creation of a > >> plugin with a malicious install-time hook script. Adding that plugin > >> to a project could corrupt the user's host machine. If that project > >> using that plugin is submitted to a build server, then the build > >> server could be corrupted. > >> > > >> > Yes, you can use lower level plugman scripts to fetch plugins and > >> > then > >> pre-scan them for install time hooks and track down all the > >> dependencies and scan them too. So this is fixable (on a build > >> server), but it's a lot of extra work; "cordova plugin add" should not > be an unsafe operation. > >> > > >> > I propose that the CLI should check to see if a plugin requires an > >> install-time hook and require the user to explicitly grant permission > >> before executing the install hook. A build server would always deny > >> permission. > >> > > >> > Is there something I'm missing here? > >> > > >> > Julian > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
