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

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.
>>>>
>>>
>