cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Proposal: hooks support for plugins
Date Mon, 21 Jul 2014 19:43:59 GMT
There will be several thousand of these ... if we choose to try to block
them all.

@purplecabbage
risingj.com


On Mon, Jul 21, 2014 at 12:40 PM, Andrew Grieve <agrieve@chromium.org>
wrote:

> Yikes! Filed this: https://issues.apache.org/jira/browse/CB-7183
>
> Anyone able to fix it?
>
>
> On Mon, Jul 21, 2014 at 1:10 PM, Sergey Grebnov (Akvelon) <
> v-segreb@microsoft.com> wrote:
>
> > Just a note, currently any plugin can add some custom file to hooks
> > directory and it will be executed
> >
> > <source-file src="src/someScript.js"
> > target-dir="../../../../../hooks/pre_package"/>
> >
> > Thx!
> > Sergey
> > -----Original Message-----
> > From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> > Mocny
> > Sent: Monday, July 21, 2014 6:28 PM
> > To: dev
> > Subject: Re: Proposal: hooks support for plugins
> >
> > Whatever the decision for default prompt/no-prompt, I suggest we add a
> > flag to do the reverse for anyone concerned.
> >
> > Aka, --prompt-for-plugin-hooks or --no-prompt-for-plugin-hooks
> >
> >
> > On Fri, Jul 18, 2014 at 5:55 PM, Shazron <shazron@gmail.com> wrote:
> >
> > > Echoing what Jesse said - having a prompt will defeat tools,
> > > especially since early on we kinda had consensus not to add in a
> > > security layer.
> > > The middle way is to add a CLI option to "auto-accept" all prompts
> > > with Y, kinda like a lot of command line tools. I think there is this
> > > pattern in Windows command line tools (
> > > https://www.microsoft.com/resources/documentation/windows/xp/all/prodd
> > > ocs/en-us/copy.mspx?mfr=true
> > > ),
> > > not sure *nix, I think for *nix the pattern is only prompt if a flag
> > > is added, the opposite.
> > >
> > > On Fri, Jul 18, 2014 at 2:26 PM, Jesse <purplecabbage@gmail.com>
> wrote:
> > > > Prompting would make it nearly impossible for third party tools to
> > > > use, there is no one to accept.
> > > > PGBuild will allow scripts, but they will only be for pre-verified
> > > plugins,
> > > > just like they deal with compiling arbitrary native code ... the
> > > > script-exec is NOT a new backdoor in this case, just another window.
> > > > When you type `npm install ios-sim` unknown, unverified (by you)
> > > > scripts are run ... how is this any different?  Any npm package with
> > > > a preinstall script will do the same, I thought we agreed that this
> > > > is a community/social
> > > issue
> > > > and not a technical/framework issue.
> > > >
> > > >>> - Not a fan of "<script>", "<hook>" might be better
> > > > I agree, or <hook-script>
> > > >
> > > >>> - context.commonModules is a great idea, but I don't think
> > > >>> exposing requireCordovaModule or elementtree is a good idea.
> > > > +1 Let's not create tech debt if we can avoid it.
> > > >
> > > >>> - Since you're making a new class, please don't call it "Hooker"
> > > > +1 some other ideas, ScriptEscort, PimpMyApp, Hookah
> > > >
> > > >
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Fri, Jul 18, 2014 at 1:47 PM, Michal Mocny <mmocny@chromium.org>
> > > wrote:
> > > >
> > > >> What about prompting during plugin install instead of prepare?
> > > >> "This plugin has hooks, would you like continue? Y/N"
> > > >>
> > > >> I'm concerned about being prompted on each prepare, especially in
> > > >> the
> > > face
> > > >> of --watch type scripts.  I'm also not sure that plugin authors
> > > >> should worry about supporting the "no" use case.  If a hook is
> > > >> optional, you
> > > can
> > > >> split it out into a separate plugin that is optionally installed.
> > > >> If
> > > its
> > > >> not optional, you should probably not install the plugin at all if
> > > >> you don't want to run the hook.
> > > >>
> > > >> WDYT?
> > > >>
> > > >> -Michal
> > > >>
> > > >>
> > > >> On Fri, Jul 18, 2014 at 4:25 PM, Andrew Grieve
> > > >> <agrieve@chromium.org>
> > > >> wrote:
> > > >>
> > > >> > Finally got to having a look. Lots of neat stuff in there! Some
> > > specific
> > > >> > feedback:
> > > >> >
> > > >> > - Not a fan of "<script>", "<hook>" might be better
> > > >> > - context.commonModules is a great idea, but I don't think
> > > >> > exposing requireCordovaModule or elementtree is a good idea.
> > > >> >   - E.g. what if we want to drop our dependency on elementtree?
> > > >> >   - I think it's important that we only expose cordova-lib's
> > > >> > public
> > > API
> > > >> to
> > > >> > hooks.
> > > >> >   - For the same reason, let's not expose cordovaUtil. just make
> > > >> > the top-level "cordova" object available. If there are other
APIs
> > > >> > that are needed, we should add them to the public API.
> > > >> > - Since you're making a new class, please don't call it "Hooker"
> > > >> > ("HookManager", "HookRunner", etc)
> > > >> > - Looks like you already added "ScriptsRunner.js"
> > > >> >   - Don't capitalize the file unless it exports as constructor
> > > >> >   - Maybe Hooker can be combined with ScriptsRunner?
> > > >> >
> > > >> > Supporting node hooks and adding plugin hooks are two big changes.
> > > Didn't
> > > >> > look to see how the commits had things split up, but I'd like
to
> > > >> > see
> > > one
> > > >> > change go in separately from the other.
> > > >> >
> > > >> > I'm a bit concerned that plugin hooks won't work well due to
it
> > > >> > being
> > > >> hard
> > > >> > to write x-platform, server builds like PGBuild, Telerik won't
> > > >> > want to
> > > >> have
> > > >> > hooks run on their servers, Thym likely can't support it.
> > > >> > Security-wise, I'd feel better about it if we prompted the user
> > > >> > before enabling plugin scripts to run. Just a simple Y/N
> > > >> > confirmation would
> > > be
> > > >> > enough. E.g.: "Plugin org.foo.bar contains an installation hook.
> > > Allow it
> > > >> > to run?"
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Fri, Jul 11, 2014 at 3:42 AM, Sergey Grebnov (Akvelon) <
> > > >> > v-segreb@microsoft.com> wrote:
> > > >> >
> > > >> > > Updated docs[1] as per review. Looking forward to community
> > > >> > > feedback
> > > >> > > regarding:
> > > >> > > 1 . Idea of defining hook scripts via config.xml and plugin.xml
> > > >> > > 2. New Script Interface for .js files (not used for /hooks
> > > >> > > scripts
> > > for
> > > >> > > backward compatibility)
> > > >> > >
> > > >> > > [1]https://github.com/apache/cordova-lib/pull/55
> > > >> > > [2]
> > > >> > >
> > > >> >
> > > >>
> > > https://github.com/MSOpenTech/cordova-lib/blob/CB-6481-hooks/cordova-l
> > > ib/templates/hooks-README.md#script-interface
> > > >> > >
> > > >> > > Thx!
> > > >> > > Sergey
> > > >> > > -----Original Message-----
> > > >> > > From: Shazron [mailto:shazron@gmail.com]
> > > >> > > Sent: Wednesday, July 9, 2014 9:26 PM
> > > >> > > To: dev@cordova.apache.org
> > > >> > > Subject: Re: Proposal: hooks support for plugins
> > > >> > >
> > > >> > > Ah ok. However I think since it is effectively deprecated
we
> > > >> > > should
> > > not
> > > >> > > advertise the old way as a supported way to do things but
add
> > > another
> > > >> > > section saying that support for "./cordova/hooks" may be
> > > >> > > removed in
> > > the
> > > >> > > future, and perhaps give a timeline for removal.
> > > >> > >
> > > >> > > On Wed, Jul 9, 2014 at 10:15 AM, Josh Soref
> > > >> > > <jsoref@blackberry.com>
> > > >> > wrote:
> > > >> > > > Shazron wrote:‎
> > > >> > > >> from the Cordova Hooks doc:
> > > >> > > >> "This directory used to exist at .cordova/hooks,
but has now
> > > >> > > >> been moved to the project root."
> > > >> > > >> -> doesn't this imply that .cordova/hooks
> > > >> > > >> does not work anymore, you should use hooks/ ?‎
> > > >> > > >
> > > >> > > > I believe it's supported for backwards compatibility
(just as
> > > >> > > > www/config.xml is) ‎
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message