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 > >
