Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of mmocny@google.com designates
 209.85.220.175 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <FFD143336FEF2D41AFA4D9CE7E119BA1594F6B96@FMSMSX112.amr.corp.intel.com>
References: 
 <FFD143336FEF2D41AFA4D9CE7E119BA1594F652D@FMSMSX112.amr.corp.intel.com>
 <CAE6O_-bfuxxmEQiWmn-h0fC5Oxv21V++o2O_SJo4mnxJUBbVQw@mail.gmail.com>
 <FFD143336FEF2D41AFA4D9CE7E119BA1594F692B@FMSMSX112.amr.corp.intel.com>
 <CAEeF2Tf668BAstWCp=fiYW29hV3tvHKeOR2aS_gshFimSUsB+A@mail.gmail.com>
 <CAEeF2TcSBfXkk4m6VpDDVhh3aZ9aOxoup+JyF7KAAT80ybxuNg@mail.gmail.com>
 <FFD143336FEF2D41AFA4D9CE7E119BA1594F6B96@FMSMSX112.amr.corp.intel.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Tue, 10 Feb 2015 14:19:16 -0500
Message-ID: 
 <CAEeF2TfrWFxKBuKL_24bkr2q79PmD8vdBqMr=5V-Kuibt1ZpLw@mail.gmail.com>
Subject: Re: Plugin Install Hooks
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b471f067f03b9050ec0c4cc

--047d7b471f067f03b9050ec0c4cc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I meant that the developer is shipping a plugin to the store which end
users will run.  If the contacts plugin is malicious, it wouldn't be
running hooks on the devs machine, it would be uploading users' contacts to
some website.  You as a developer should vet the plugin to make sure it
isn't.

At the end of the day, in practice, it just comes down to trust.  Download
plugins from trusted sources.  When there is no trust, you have to sandbox
and audit.

On Tue, Feb 10, 2015 at 12:22 PM, Horn, Julian C <julian.c.horn@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=E2=
=80=99t
> trust the plugins you trust.
>
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@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 serv=
er
> you control and can sandbox.
>
> On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny <mmocny@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.horn@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 hook=
s!
> >> 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:shazron@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.horn@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-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>

--047d7b471f067f03b9050ec0c4cc--