search

WICG / signature-based-sri

Signature-based Resource Loading Restrictions
https://wicg.github.io/signature-based-sri/
Other
20 stars 2 forks source link

Allow a default public key to use #9

Open devd opened 6 years ago

devd commented 6 years ago

It can be annoying and wasteful to repeatedly mention the same public key in all the script tags. Different options to fix this could be:

[] Repurpose something like require-sri-for script to pretend that there's an integrity attribute on every element that doesn't already have one, filling its value with something [] Use something like a meta tag to specify a default

I personally feel second is better because this feels something that should be separate from SRI.

Although, other ideas are welcome!

mikewest commented 1 day ago

Noting this as a potential enhancement (several years later...).

ddworken commented 1 day ago

I'll also add that I think a best-practice for signature-based SRI will be using a unique key for each resource (since that avoids the issue described in #5), in which case there likely won't be any duplicate public key references. So I suspect that the utility of having a default public key won't be too significant with this usage model.

mikewest commented 22 hours ago

I think we should probably document deployment scenarios we expect developers to explore. Some systems will certainly benefit from multiple keys, other more monolithic applications seem likely to want to ensure content has run through some specific build system and would happily rely on a single key.

I'm not sure that justifies a defaulting mechanism (and defining the override behavior that would surely be necessary), but it doesn't seem like an unreasonable thing to ask for. I'd suggest that this is something we can tack on in the future if we see developer demand. Leaving it as an "enhancement" makes sense to me.