The command line switches have been finalized for 3.6.0. Once that is merged, 
we should be good to release 3.6.0 from windows perspective. 

-----Original Message-----
From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian 
Clelland
Sent: Tuesday, August 12, 2014 1:00 PM
To: dev@cordova.apache.org
Subject: Re: [Discuss] 3.6.0 Release

I think that A) is likely the feasible solution for 3.6.0.

B) seems like a 4.0-scope project (but an interesting one; I hadn't considered 
it working in that direction) We'd probably spend a while debating the 
particulars -- I don't know if changing the CSP syntax is a good idea, or if 
we'd want an X-Navigation-Policy header of our own to play with -- but I think 
that a drastic change of direction like that would require a major version 
update if it's in core.

The other alternative I see (which goes back to the thread that Andrew
linked) is to pull 1, 2, and 3 out of the core, and have plugins for all of it.

What changes would we need to make to the plugin architecture to make that 
happen?



On Tue, Aug 12, 2014 at 3:16 PM, Andrew Grieve <agri...@chromium.org> wrote:

> A malicious XSS that navigates the page would probably opt to not 
> include cordova.js :P.
>
> So - I see there being three kinds of things to have whitelists for:
> 1) Top-level navigations,
> 2) intents (on supported platforms)
> 3) resources / CSP-related requests.
>
> According to CSP docs here:
>
> https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_d
> irectives
> You cannot use CSP to control 1).
>
> Right now the whitelist tries to cover 1) and 3), but I think from 
> this
> thread: http://markmail.org/thread/hbr5tlopbbl4pnl3
> That we agreed to change it to cover only 1), Although this 
> conversation will likely be more all-encompassing.
>
> Options for specifying 1), 2), 3):
> A) Keep all three separate, with 1) and 2) in config.xml, and 3) in a 
> <meta> added by the user
> B) Augment the CSP syntax with support for 1) and 2) (as Parashuram 
> suggested), and have cordova.js extract 1) and 2) out of the <meta>, 
> which is added by the user. Make the whitelists empty until cordova.js 
> does the extraction.
> C) Have them all specified in config.xml, and have Cordova somehow 
> enforce
> 3) on page load.
>
> Another factor: What is put in config.xml is open to be modified by 
> plugins (for better or for worse). Might be useful, but I'm not sure 
> of a concrete use-case (maybe Camera plugin would need this?)
>
> As Ian pointed out, C) isn't really feasible on Android in all cases, 
> but I'm torn between A) and B).
>
>
>
> On Tue, Aug 12, 2014 at 11:59 AM, Michal Mocny <mmo...@chromium.org>
> wrote:
>
> > Any page navigations have to include cordova.js, right?  What about 
> > injecting the meta tag before deviceready?
> >
> >
> > On Tue, Aug 12, 2014 at 11:54 AM, Ian Clelland 
> > <iclell...@chromium.org>
> > wrote:
> >
> > > I love the idea of using CSP for this, especially because it 
> > > handles
> > things
> > > that our whitelist intercept code can't, like <video> tags and
> > WebSockets.
> > >
> > > The problem that I've found with it is that we can only enforce it 
> > > for single-page apps. We can inject our own CSP headers into the
> > application's
> > > start page very easily, but if the user can leave that page and 
> > > load another, then the headers will no longer apply. The WebView 
> > > interface
> > won't
> > > let use add headers to subsequent pages, so it's up to the 
> > > developer to include them in a <meta> tag instead. (and malicious 
> > > attackers, of
> > course,
> > > won't)
> > >
> > > For now, I would encourage devs to include that <meta> tag on 
> > > *all* of
> > the
> > > pages in their apps, but we can't do it automatically.
> > >
> > > If it turns out that we can, then I'd be on board with including 
> > > that
> in
> > > the 4.0 branch. It's a much better way to do it. Then we'd only 
> > > need
> the
> > > second whitelist for launching intents, I think.
> > >
> > > Ian
> > >
> > >
> > > On Tue, Aug 12, 2014 at 11:48 AM, Parashuram Narasimhan (MS OPEN 
> > > TECH)
> <
> > > panar...@microsoft.com> wrote:
> > >
> > > > Had a quick question on the whitelists. I remember that there 
> > > > was
> talk
> > of
> > > > using CSP to fix this issue. A CSP file may not be backward
> compatible,
> > > but
> > > > could potentially just give us one list instead of 2 whitelists. 
> > > > The
> > CSP
> > > > file may be like the following
> > > >
> > > > Content-Security-Policy:
> > > >         script-src 'self', foo.com, bar.com
> > > >         img-src cdn.com
> > > >         intent-src mail, sms
> > > >
> > > > Note the new intent-src directive, that is basically used to 
> > > > launch external programs. Do you think this could be something 
> > > > we can look
> at,
> > > for
> > > > 4.0 ? I am not sure if our whitelist xml file maps to a W3C 
> > > > spec, but
> > CSP
> > > > seems more like a standard. This is breaking, and 4.0 may be the
> right
> > > time
> > > > to do it ?
> > > >
> > > > -----Original Message-----
> > > > From: iclell...@google.com [mailto:iclell...@google.com] On 
> > > > Behalf
> Of
> > > Ian
> > > > Clelland
> > > > Sent: Tuesday, August 12, 2014 8:30 AM
> > > > To: dev@cordova.apache.org
> > > > Subject: Re: [Discuss] 3.6.0 Release
> > > >
> > > > I've created CB-7291 for the whitelist issue, and I've ported 
> > > > the
> code
> > > > from June to the new-style configuration architecture and 
> > > > committed
> it
> > > to a
> > > > named CB-7291 branch on cordova-android.
> > > >
> > > > If anyone has any thoughts/opinions on the syntax or the 
> > > > proposal
> > itself,
> > > > or on what the defaults should be for new and upgrading 
> > > > applications, please chime in on the issue.
> > > >
> > > >
> > > >
> > > > On Mon, Aug 11, 2014 at 11:26 AM, Parashuram Narasimhan (MS OPEN
> TECH)
> > <
> > > > panar...@microsoft.com> wrote:
> > > >
> > > > > I think we should also finalize on the platform switches so 
> > > > > that we all agree on a pattern (even if it is different across 
> > > > > platforms).
> > > > > This way, we can release 3.6.0 with a set of switches, and 
> > > > > ensure
> > that
> > > > > it is backward compatible.
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: iclell...@google.com [mailto:iclell...@google.com] On 
> > > > > Behalf
> > Of
> > > > > Ian Clelland
> > > > > Sent: Monday, August 11, 2014 8:00 AM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: Re: [Discuss] 3.6.0 Release
> > > > >
> > > > > I'll see about committing that today; I've had to reorganize 
> > > > > it
> quite
> > > > > a bit after the Big Config Refactor.
> > > > >
> > > > > Joe, I'm pretty certain that your code is still in master, but 
> > > > > definitely add those tests to make sure, and to make sure we 
> > > > > don't
> > > > regress.
> > > > >
> > > > > Ian
> > > > >
> > > > >
> > > > > On Mon, Aug 11, 2014 at 10:52 AM, Marcel Kinard <
> cmarc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I agree with Joe.
> > > > > >
> > > > > > On Aug 11, 2014, at 10:02 AM, Joe Bowser <bows...@gmail.com>
> > wrote:
> > > > > >
> > > > > > > Let's not release until the new whitelist is figured out.  
> > > > > > > That feature
> > > > > > is
> > > > > > > too important.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to