- From: Patrick Toomey <patrick.toomey@github.com>
- Date: Tue, 22 Dec 2015 17:07:04 +0000
- To: Joel Weinberger <jww@chromium.org>, public-webappsec@w3.org
- Message-ID: <CAN4Q8dC6WocH3qTM2PdCC7QGg21MZrYtTQShjanJje5e0RKqjA@mail.gmail.com>
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. >> >
Received on Tuesday, 22 December 2015 17:07:42 UTC