You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Horn, Julian C" <ju...@intel.com> on 2015/02/09 17:28:26 UTC
Plugin Install Hooks
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
Re: Plugin Install Hooks
Posted by Andrew Grieve <ag...@chromium.org>.
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 <ju...@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: 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 server
> you control and can sandbox.
>
> On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny <mm...@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
> > <ju...@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: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
> >> <ju...@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
>
Re: Plugin Install Hooks
Posted by Michal Mocny <mm...@chromium.org>.
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 <ju...@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: 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 server
> you control and can sandbox.
>
> On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny <mm...@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
> > <ju...@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: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
> >> <ju...@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
>
RE: Plugin Install Hooks
Posted by "Horn, Julian C" <ju...@intel.com>.
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: 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 server you control and can sandbox.
On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny <mm...@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
> <ju...@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: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
>> <ju...@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
Re: Plugin Install Hooks
Posted by Michal Mocny <mm...@chromium.org>.
..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 <mm...@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 <ju...@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: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 <ju...@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
>>
>>
>
Re: Plugin Install Hooks
Posted by Michal Mocny <mm...@chromium.org>.
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 <ju...@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: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 <ju...@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
>
>
RE: Plugin Install Hooks
Posted by "Horn, Julian C" <ju...@intel.com>.
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: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 <ju...@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
Re: Plugin Install Hooks
Posted by Shazron <sh...@gmail.com>.
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 <ju...@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