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
