Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRI: specify verification of CSS-loaded subresources #306

Open
fmarier opened this issue Apr 25, 2015 · 8 comments

Comments

@fmarier
Copy link
Contributor

commented Apr 25, 2015

Tab and Anne are poking at adding fetch() to some spec somewhere which would allow CSS files to specify various arguments to the fetch algorithm while requesting resources. Detail on the proposal is at https://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0129.html. Once that is specified, we can proceed defining an integrity argument that would allow integrity checks in CSS.

@fmarier fmarier added the SRI label Apr 25, 2015

@fmarier fmarier modified the milestone: SRI-v1-LC Apr 25, 2015

fmarier pushed a commit to fmarier/webappsec that referenced this issue Apr 25, 2015
@mozfreddyb mozfreddyb referenced this issue Apr 25, 2015
7 of 9 tasks complete
@annevk

This comment has been minimized.

Copy link
Member

commented Apr 27, 2015

Not sure if this is still on @tabatkins radar.

@tabatkins

This comment has been minimized.

Copy link
Member

commented Apr 27, 2015

It had slipped my mind! I'll put this on my more urgent todo list.

@tabatkins

This comment has been minimized.

Copy link
Member

commented Apr 27, 2015

Oh wait, I actually did do part of this. We don't need a fetch() function, because I was able to switch url() from being a special form to being a normal function, so you can now use arguments inside of it. So url("http://example.com" integrity DEADBEEF) is clear to happen now.

@fmarier

This comment has been minimized.

Copy link
Contributor Author

commented Apr 28, 2015

Is this something we want in v1? /cc @metromoxie @mozfreddyb @devd

At this stage, my personal opinion (in the interest of getting to CR) would be to postpone anything that requires implementation changes unless:

  1. it's a security problem,
  2. it has forward compatibility implications, or
  3. it will prevent wide adoption

I can see an argument for #1, but I would argue that what we have is still better than the status quo and that it allows authors to protect the first level of sub-resources quite well. We can tackle "recursive integrity" in v2.

@devd

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2015

I don't think this is needed in v1

@tabatkins

This comment has been minimized.

Copy link
Member

commented Apr 28, 2015

Leaving url() as it is for now obviously isn't any worse than the status quo (because it is the status quo), so yeah, delaying to v2 is fine.

@metromoxie

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2015

Agreed with delaying to v2.

@mozfreddyb mozfreddyb added this to the SRI-next milestone Apr 29, 2015

mikewest pushed a commit to mikewest/webappsec that referenced this issue Jun 29, 2015
Merge pull request w3c#306 from tantek/patch-12
use time element for the date instead of two spans
@v6ak

This comment has been minimized.

Copy link

commented Apr 21, 2018

Just an idea: enforcement of SRI on transitive dependencies, maybe as a part of CSP.

In theory, someone might statically verify that the stylesheet does not fetch any external resources without SRI, so the enforcement is not needed.

In practice, it is additional hassle that many developers will not do, so such enforcement could be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.