Re: Updated script hash proposal (non spec text)

> However, when building this, I couldn't find the script-hash grammar
> on the CSP 1.1 spec. Are there any plans to update the draft soon?
> It's hard to get working examples without a spec - one has to dig
> into the individual browser source code to see how things are done.

A proposed patch to specify nonce-source and hash-source is just waiting 
on a merge (I sent a reminder).

> I recommend that we specify SHA256/384/512 on the spec and drop SHA1
> completely. There are no backwards compatibility issues here, so
> there is no need to support a hash function which might not be
> collision-resistant.

That patch only allows sha256/384/512.

-Garrett

On 12/10/2013 03:16 PM, Dionysis Zindros wrote:
>
>
>
> On Tue, Dec 10, 2013 at 2:55 PM, Garrett Robinson <grobinson@mozilla.com
> <mailto:grobinson@mozilla.com>> wrote:
>
>     On 12/10/2013 02:51 PM, Neil Matatall wrote:
>
>         Just wanted to point out an example of this in the wild
>         http://dionyziz.logimus.com/__content-security-policy/
>         <http://dionyziz.logimus.com/content-security-policy/>
>
>
>     Awesome! The Firefox WIP is almost ready to land too. One thing - we
>     only support sha256/384/512, due to well known concerns with SHA1's
>     collison resistance. This example is using sha1, which it says is
>     the only algorithm Chrome supports at the moment. Do we want to spec
>     the supported algorithms for 1.1?
>
>
> I'll update the example to add test cases for SHA256/384/512. By the
> way, I moved it to an HTTPS/HSTS URL to illustrate good practices, as
> CSP builds on the assumption that HTTP headers cannot be tampered with:
>
> https://dionyziz.com/content-security-policy/
>
> However, when building this, I couldn't find the script-hash grammar on
> the CSP 1.1 spec. Are there any plans to update the draft soon? It's
> hard to get working examples without a spec - one has to dig into the
> individual browser source code to see how things are done.
>
> I recommend that we specify SHA256/384/512 on the spec and drop SHA1
> completely. There are no backwards compatibility issues here, so there
> is no need to support a hash function which might not be
> collision-resistant.
>
> So, let's update the CSP 1.1 draft to add the grammar for this.
>
>
>         Check out
>         http://dionyziz.logimus.com/__content-security-policy/csp-__js.php
>         <http://dionyziz.logimus.com/content-security-policy/csp-js.php>
>         in Chrome canary with experimental flags set :)
>
>
>
>         On Tue, Dec 3, 2013 at 1:41 PM, Garrett Robinson
>         <grobinson@mozilla.com <mailto:grobinson@mozilla.com>> wrote:
>
>             Attached updated patch to
>
>             1. create a "base64-value" rule so we don't have to repeat
>             ourselves in
>             separate "nonce-source" and "hash-source" rules
>             2. limit ='s to be a max of 2 and only allowed at the end of
>             the string
>
>             Alternatively, might we just refer to "base64 string from
>             RFC 3548" [0],
>             the way we do for the "scheme" rule?
>
>             [0] http://tools.ietf.org/html/__rfc3548.html#section-3
>             <http://tools.ietf.org/html/rfc3548.html#section-3>
>
>             -Garrett
>
>             On 11/26/2013 10:57 AM, Joel Weinberger wrote:
>
>                 I, too, support the second option as well (and, in fact,
>                 that is how
>                 we've implemented it for hashes in Chrome).
>
>                 I don't suppose there's a way to specify that the '='
>                 should only appear
>                 at the end of the value (and there should be 2 or less)?
>                 --Joel
>
>
>                 On Mon, Nov 25, 2013 at 11:09 AM, Garrett Robinson
>                 <grobinson@mozilla.com <mailto:grobinson@mozilla.com>
>                 <mailto:grobinson@mozilla.com
>                 <mailto:grobinson@mozilla.com>>__> wrote:
>
>                       On 11/25/2013 01:24 PM, Neil Matatall wrote:
>                       > Ah yes. Oops. I support the second option as well.
>                       >
>                       > Should "1*( ALPHA / DIGIT / "+" / "/" / "=" )"
>                   be its own
>                       > symbol/definition/whatever to make it clear that
>                 the values will have
>                       > the same rules?
>
>                       I was thinking of doing that, but wasn't sure how
>                 to write it in the
>                       spec. Can we just call it base64-value?
>
>
>
>

Received on Tuesday, 10 December 2013 23:21:44 UTC