Add SRI hash type option

[migueldemoura]

• [X] I tried updating to the latest version.
  • [ ] I can't, there is an issue.
• [ ] I Am on Windows
  • [ ] Ubuntu Bash on Windows
  • [ ] Fedora Bash on Windows
  • [ ] Other Bash on Windows
• [X] I Am on Linux
  • [X] Ubuntu
  • [ ] Fedora
• [ ] I Am on macOS
• [ ] I'm on Docker
  • [ ] I understand Docker may be unsupported.

Description

I'd be nice if we were able to change the integrity hash type between sha256, sha384 and sha512. Below you can find a design suggestion.

Steps

{% asset 'main.css' integrity-hash='sha384' %}

Output

<link rel="stylesheet" type="text/css" href="main.css" integrity="sha384-something" crossorigin="anonymous">

[envygeeks]

Is there any particular reason? It's not that it's a bad idea (I'm pretty neutral on this) but it would be nice to know if there are any bugs somewhere that I can look into (especially browserwise), at the end of the day though I would probably just opt integrity=sha384 since the chances of us accepting an external hash are pretty slim, since it's a calculated effort.

[migueldemoura]

I believe there are no bugs. As for using integrity instead of integrity-hash or any other name, I believe it would be unexpected behaviour from a user's perspective. Not to mention it prevents manually providing such data, as you mentioned.

[envygeeks]

I don't want you to provide such data, and would never allow it, lets be clear about that ahead of time. I would never allow a user to jeopardize the integrity of the data I output by allowing them to output a hash. There will be no compromise on that part, and if it's already allowed, it's a security bug.

[migueldemoura]

I don't think that specific user choice is a security bug, although I can see why you made such design decision. Either way, I feel using the same key isn't intuitive.

[envygeeks]

For the user it's not, for me it is, because it compromises the integrity of the data I output. While I wouldn't outright call it a security bug, or even a major one, or even flag it as such, I would still consider it one behind closed doors (I'm no fan of security theater which is why I would never come out and treat it as such, I would just fix it as an everyday bug, because it does no real harm at the end of the day) but the design choice was always that there are pieces of data we must control in order to make things clean.

On the key name, I would think integrity is the most intuitive key, but integrity along is neither here nor there for me. It's the term "hash" that hangs me up. Maybe integrity:algorithm=sha512, since we don't allow users to set a value on integrity making it a hash internally from an external route breaks nothing in our own API's. I do know the preferred route for our stuff is always ":" rather than "-"

[migueldemoura]

It would simply be user input, meaning it would have to be treated as such. The only use case I had in mind could be detached from the jekyll-assets build process anyway, so no big deal.

Regarding the key name, integrity could be used especially if this isn't the only case of such behaviour.

[envygeeks]

Can you elaborate on paragraph 1 more? I'm intrigued to know more so I can see if I have the wrong stance on the subject. There was one time I thought this kind of thing would be useful, but I can't really recall it right now.

If you're fine with the keyname integrity (unless I'm reading wrong) I'll feature it up.

[migueldemoura]

I have a few projects that use tools outside of my control that modify some assets along the pipeline. For those, I needed a way of programatically changing the SRI hash. I ended up using an external script, which is a better option than embeding it into the jekyll build process anyway.

As for having different hash types, that'd be nice. Let me know if I can help.

[envygeeks]

If they work before I guess I can see that, but it seems a bit hacky then just doing it afterwards with an HTML processor that has an AST or something that can quickly modify the HTML. Ultimately though you could always insert yourself into our process and add your own integrity structure with a plugin which would be ideal if that's what you're looking for, you could even use a plugin from within our system to call your pipeline as a proxy.