W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2013

Re: Updated script hash proposal (non spec text)

From: Garrett Robinson <grobinson@mozilla.com>
Date: Tue, 10 Dec 2013 14:55:41 -0800
Message-ID: <52A79BED.10505@mozilla.com>
To: Neil Matatall <neilm@twitter.com>
CC: Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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/

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?

> Check out 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> 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
>>
>> -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>> 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 22:56:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC