Re: Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Sep 22, 2017, at 4:24 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>
> On Fri, Sep 22, 2017 at 4:18 PM, Christoph Kerschbaumer
> <cker...@gmail.com> wrote:
>> We plan to ship the CSP directive worker-src within Firefox 58.
>
> Will we also start enforcing script-src for workers? It seems good
> that if you restrict script it actually stops all scripts.

If worker-src is not present in an enforced policy, but script-src is, then yes.

[Daniel Veditz]

On Fri, Sep 22, 2017 at 7:24 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> > We plan to ship the CSP directive worker-src within Firefox 58.
>
> Will we also start enforcing script-src for workers? It seems good
> that if you restrict script it actually stops all scripts.
>

​Yes. That's what we enforced under our original proposal and under CSP1.
Then the spec changed in a non-backwards compatible way and left worker
scripts unprotected by default (caused a bunch of Firefox OS breakage). Now
it's changing again in CSP3, and breaking backwards compatibility again.

​Christoph said

> For backwards compatibility child-src will still be enforced for:
> * workers (if worker-src is not explicitly specified)
>

​But the spec says the fallback is script-src. Surely anyone who uses
child-src will also have a script-src so how is this going to work? How
does Chrome work?

Filed https://github.com/w3c/webappsec-csp/issues/239 to remove the worker
mentions from child-src since the rest of the spec (including the algorithm
in that section) implies that's incorrect.

​-Dan Veditz

[Christoph Kerschbaumer]

> On Sep 22, 2017, at 10:27 PM, Daniel Veditz <dve...@mozilla.com> wrote:
> ​Christoph said
> For backwards compatibility child-src will still be enforced for:
> * workers (if worker-src is not explicitly specified)
>
> ​But the spec says the fallback is script-src. Surely anyone who uses child-src will also have a script-src so how is this going to work? How does Chrome work?

It’s too confusing, but that’s why I initially filed https://github.com/w3c/webappsec-csp/issues/238 <https://github.com/w3c/webappsec-csp/issues/238>, because the spec still mentioned that child-src will govern workers in the absence of worker-src.

>
> Filed https://github.com/w3c/webappsec-csp/issues/239 <https://github.com/w3c/webappsec-csp/issues/239> to remove the worker mentions from child-src since the rest of the spec (including the algorithm in that section) implies that's incorrect.

Ultimately I agree with your comment in issue 238. Probably the fallback should be, worker-src, child-src, and then script-src, default-src. Either way, I think we can find a solution within issue 239, thanks for filing.

[Daniel Veditz]

I'm not sure I agree with my own comment -- that's an insane fall-back
path. Might ease some backwards compatibility problems, but we don't know
how many of those there will be. But then we have to live with the insanity
forever.

-Dan Veditz

On Mon, Sep 25, 2017 at 1:01 AM, Christoph Kerschbaumer <cker...@gmail.com>
wrote:

>
> On Sep 22, 2017, at 10:27 PM, Daniel Veditz <dve...@mozilla.com> wrote:
> ​Christoph said
>
>> For backwards compatibility child-src will still be enforced for:
>> * workers (if worker-src is not explicitly specified)
>>
>
> ​But the spec says the fallback is script-src. Surely anyone who uses
> child-src will also have a script-src so how is this going to work? How
> does Chrome work?
>
>
> It’s too confusing, but that’s why I initially filed

> https://github.com/w3c/webappsec-csp/issues/238, because the spec still

> mentioned that child-src will govern workers in the absence of worker-src.
>
>

> Filed https://github.com/w3c/webappsec-csp/issues/239 to remove the

[James Graham]

On 22/09/17 15:18, Christoph Kerschbaumer wrote:
> Hey Everyone,
>
> within CSP2 workers used to be governed by the child-src directive [0]. CSP3 introduces the worker-src directive [1] wich governs Workers, SharedWorkers as well as ServiceWorkers. Please note that the child-src directive has been deprecated within CSP3 in favor of worker-src as well as frame-src.

>
> For backwards compatibility child-src will still be enforced for:
> * workers (if worker-src is not explicitly specified)

> * frames (if frame-src is not explicitly specified)

>
> We plan to ship the CSP directive worker-src within Firefox 58.

Do we have cross-browser (i.e. web-platform) tests for this feature?

[Christoph Kerschbaumer]

Not yet. We just agreed with Chrome on the same fallback mechanism, see [1].
We are about to add mochitests for all the different fallback mechanisms though.

[1] https://github.com/w3c/webappsec-csp/issues/239#issuecomment-337488401

[James Graham]

What's the reason for writing mochitests? It seems like this is
something where we benefit from shared tests.

[Christoph Kerschbaumer]

Reason is simple, I have already written the mochitests for it. But I agree, we should have web-platform tests for it.

[Mike West]

We do have `worker-src` tests, FWIW:
https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/.
We'll likely need to adjust things based on the fallback mechanism y'all
are running with (and Chrome will need to drop the weird contortions we
implemented for back-compat), but I'd hope you would be able to use those
rather than writing mochitests.


-mike

On Wed, Oct 18, 2017 at 11:51 AM, Christoph Kerschbaumer <cker...@gmail.com

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Christoph Kerschbaumer]

> On Oct 18, 2017, at 3:30 PM, Mike West <mk...@chromium.org> wrote:
>
> We do have `worker-src` tests, FWIW: https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/ <https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/>. We'll likely need to adjust things based on the fallback mechanism y'all are running with (and Chrome will need to drop the weird contortions we implemented for back-compat), but I'd hope you would be able to use those rather than writing mochitests.

Quick update on worker-src:
- We are going to ship worker-src with the fallback to child-src, script-src, default-src within Firefox 58.
- There are some web-platform-tests, as pointed out by Mike, which we are going to extend within [1] to account for the fallback.

Thanks,
Christoph

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1409706

>
> -mike
>
> On Wed, Oct 18, 2017 at 11:51 AM, Christoph Kerschbaumer <cker...@gmail.com <mailto:cker...@gmail.com>> wrote:

>
> > On Oct 18, 2017, at 11:41 AM, James Graham <ja...@hoppipolla.co.uk <mailto:ja...@hoppipolla.co.uk>> wrote:
> >
> > On 18/10/17 10:35, Christoph Kerschbaumer wrote:

> >>> On Oct 18, 2017, at 11:25 AM, James Graham <ja...@hoppipolla.co.uk <mailto:ja...@hoppipolla.co.uk>> wrote:
> >>>
> >>> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
> >>>> Hey Everyone,
> >>>> within CSP2 workers used to be governed by the child-src directive [0]. CSP3 introduces the worker-src directive [1] wich governs Workers, SharedWorkers as well as ServiceWorkers. Please note that the child-src directive has been deprecated within CSP3 in favor of worker-src as well as frame-src.
> >>>> For backwards compatibility child-src will still be enforced for:
> >>>> * workers (if worker-src is not explicitly specified)
> >>>> * frames (if frame-src is not explicitly specified)
> >>>> We plan to ship the CSP directive worker-src within Firefox 58.
> >>>
> >>> Do we have cross-browser (i.e. web-platform) tests for this feature?
> >> Not yet. We just agreed with Chrome on the same fallback mechanism, see [1].
> >> We are about to add mochitests for all the different fallback mechanisms though.
> >
> > What's the reason for writing mochitests? It seems like this is something where we benefit from shared tests.
>
> Reason is simple, I have already written the mochitests for it. But I agree, we should have web-platform tests for it.
>
> _______________________________________________
> dev-platform mailing list

> dev-pl...@lists.mozilla.org <mailto:dev-pl...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform <https://lists.mozilla.org/listinfo/dev-platform>
>