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

Allow a default public key to use #9

Open
devd opened this issue Nov 29, 2017 · 3 comments
Open

Allow a default public key to use #9

devd opened this issue Nov 29, 2017 · 3 comments

Comments

@devd
Copy link

devd commented Nov 29, 2017

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
Copy link
Member

mikewest commented Oct 9, 2024

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

@ddworken
Copy link
Contributor

ddworken commented Oct 9, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants