Re: [CSP] "sri" source expression to enforce SRI

FWIW, I think either approach is fine. I know that, in general, we've been
concerned about CSP bloat, so for that reason alone it might be worth
moving it to its own header. But I don't really care at all either way.

On Tue, Dec 22, 2015 at 2:28 PM Richard Barnes <rbarnes@mozilla.com> wrote:

> I'm not sure I agree with that, Brad :)  CSP is where we place
> restrictions on loading things, and "must have SRI" is a restriction on
> loading things.
>
> On Tue, Dec 22, 2015 at 2:26 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> Yeah, we'd discussed a SRI policy header / meta tag to express a number
>> of things like this, it just got dropped from v1 to get it out the door.
>> Not sure shoehorning it into CSP is the right choice, especially since the
>> reporting mechanism is already being factored out into its own, reusable,
>> feature.  Might be simpler to define a standalone header.
>>
>> On Tue, Dec 22, 2015 at 11:24 AM Richard Barnes <rbarnes@mozilla.com>
>> wrote:
>>
>>> Some sort of "must-sri" directive is something we had considered inside
>>> Mozilla for some of our properties, so this does seem like a productive
>>> thing to look at.  I don't have any personal biases about how exactly to
>>> express it.
>>>
>>>
>>> On Tue, Dec 22, 2015 at 12:07 PM, Patrick Toomey <
>>> patrick.toomey@github.com> wrote:
>>>
>>>> Yeah, a separate directive probably makes sense. I was originally
>>>> thinking it fit into the "locations that are safe" pattern since we are
>>>> stating that a location is only safe if it has a known hash (using SRI)
>>>> from that location. But, I realize that is a stretch. And, you have a good
>>>> point about being able to put other SRI related things in if we have a
>>>> separate directive. So, yeah, that is probably the cleaner way to go.
>>>> Thanks for opening the tracking issue.
>>>> On Tue, Dec 22, 2015 at 9:32 AM Joel Weinberger <jww@chromium.org>
>>>> wrote:
>>>>
>>>>> That's a good point about SRI in general; it's hard to know if you've
>>>>> forgotten to SRI anything. I'm not sure source-expression is the right
>>>>> place to put it in CSP, though, as that's meant to be "locations that are
>>>>> safe," and that's not exactly what you're requesting. It probably makes
>>>>> sense to have an 'sri-options' directive, though, since we'll probably want
>>>>> SRI 'report-only' eventually anyway.
>>>>>
>>>>> I've filed this as a feature request in GitHub, too:
>>>>> https://github.com/w3c/webappsec-subresource-integrity/issues/23
>>>>> --Joel
>>>>>
>>>>>
>>>>> On Tue, Dec 22, 2015 at 2:50 AM Patrick Toomey <
>>>>> patrick.toomey@github.com> wrote:
>>>>>
>>>>>> We recently deployed subresource integrity across GitHub.com:
>>>>>> https://github.com/blog/2058-github-implements-subresource-integrity.
>>>>>> However, a few days after deployment we determined that one of our JS
>>>>>> scripts did not have an "integrity" attribute assigned to it. It was our
>>>>>> intent to add the integrity attribute to all subresources on GitHub.com. We
>>>>>> statically vendor in all CSS/JS and use Sprockets (SRI support was added in
>>>>>> https://github.com/sstephenson/sprockets/pull/645) to package these
>>>>>> assets for production deployments. There happened to be one JS file that
>>>>>> had not been vendored, and hence was not being packaged by Sprockets. This
>>>>>> violated two of our goals:
>>>>>>
>>>>>> * Not allowing any dynamically sourced JS (we vendor everything to
>>>>>> ensure what is in version control is what is used in production)
>>>>>> * Enforcing SRI on all supported subresources on GitHub.com
>>>>>>
>>>>>> Reflecting back on this situation, it would have been nice to have
>>>>>> support in CSP for a source expression such as
>>>>>> "sri"/"sri-only"/"sri-naming-things-is-hard" to ensure SRI is being used
>>>>>> everywhere. In the above scenario, the related JS would have failed to load
>>>>>> and we would have identified both of the issues listed above in testing.
>>>>>>
>>>>>
>>>
>