adding sri modal to codeorigin

[jmervine]

Hello!

Per the discussions on gh:jquery/codeorigin.jquery.com#20 I'm adding the SRI modal as an onclick popin for each cdn file link. This is in direct support of gh:jquery/codeorigin.jquery.com#22. I've attached a screenshot of the result here:

Notes:

• I'm not 100% about the method used to include both style and script tags in the correct location. I attempted to use wp_enqueue_script and wp_enqueue_style respectively, without success. I'm new to Wordpress, so I may have been doing something incorrectly. Any direction here would be appreciated.
• I did my best to follow the style guide. I apologies if I missed anything. I'm happy to make any updates necessary. That said, the versioned css and js files includes were added as is from their sources.

Thanks and cheers! J

(cc @jdorfman @scottgonzalez)

[jdorfman]

Looks good to me

[dmethvin]

LGTM but I'll defer to @scottgonzalez who has been following this more closely and knows the setup better.

[mgol]

Do we want to have a page with hashes for all past versions for people that can't yet download the newest one?

[scottgonzalez]

Do we want to have a page with hashes for all past versions for people that can't yet download the newest one?

The hashes are already computed for every version. I've also suggested that we expose https://code.jquery.com/resources/sri-directives.json in https://github.com/jquery/codeorigin.jquery.com/pull/22#issuecomment-177702136

[mgol]

The hashes are already computed for every version.

Where are they kept?

I've also suggested that we expose https://code.jquery.com/resources/sri-directives.json in jquery/codeorigin.jquery.com#22 (comment)

Since the goal of the SRI is to prevent injecting a rogue script in case of a CDN poisoning, putting a file listing the hashes on this very CDN doesn't sound like the best option.

[scottgonzalez]

Where are they kept?

Umm...they're generated on deploy for the CDN. I'm getting the feeling you haven't looked at the related PR.

Since the goal of the SRI is to prevent injecting a rogue script in case of a CDN poisoning, putting a file listing the hashes on this very CDN doesn't sound like the best option.

And the values that every user will insert into their scripts comes directly from the CDN. I'm not sure where else these would be listed.

[mgol]

Umm...they're generated on deploy for the CDN. I'm getting the feeling you haven't looked at the related PR.

Yeah, sorry, I see it now.

And the values that every user will insert into their scripts comes directly from the CDN. I'm not sure where else these would be listed.

Those values are needed only for developers, end users don't download them. Hence, the CDN is not necessary for that, they may as well be kept somewhere on our sites, i.e. places that are separate from CDNs. We'd have to first switch our sites to HTTPS-only, though.

[scottgonzalez]

Hence, the CDN is not necessary for that, they may as well be kept somewhere on our sites, i.e. places that are separate from CDNs. We'd have to first switch our sites to HTTPS-only, though.

I'm really not sure what setup you have in mind. It would certainly require whatever other random site you choose to have the CDN as a dependency for getting the hashes.

[mgol]

I'm really not sure what setup you have in mind. It would certainly require whatever other random site you choose to have the CDN as a dependency for getting the hashes.

Only for past releases; new ones are generated offline, on a computer of the person doing the release.

[scottgonzalez]

Only for past releases; new ones are generated offline, on a computer of the person doing the release.

I'm not sure how you got that impression. The hash will always be generated by the production build server during deploy. Perhaps you can explain why you think this would not be the case based on the other PR.

[dmethvin]

I think the scenario that the SRI integrity hash is addressing is this one:

• You start development for your web site and decide to use files from the CDN.
• You calculate the integrity hash and include it in the script tags referencing the CDN.
• If the files are later changed on the CDN, for example by an attacker, the integrity hash will not match and the code will not run.

If someone hacks jquery-1.11.1.js on the web site months after it's put down, there should be thousands if not millions of web sites with the correct hash value, they would be protected, and we'd know about the problem in short order.

That's why I'm hesitant to fix the map reference in the minified jQuery 1.9.1 file by editing it. Anyone using SRI or keeping their own hashes would notice that the file has been changed two years after it was put on the CDN.

[jmervine]

@scottgonzalez Thanks for the feedback, comments. I'll address / answer shortly. Dealing with some other fires elsewhere at the moment.

[jmervine]

@scottgonzalez I've addressed some of the low hangers. I'll get back to the rest shortly. I didn't work up the client side js/css, and have asked @jdorfman to review those parts, he or I will start addressing those parts next.

Cheers!

PS: I will most certainly squash commits once all comments have been address. :)

[jdorfman]

we close @scottgonzalez ?

[jmervine]

@scottgonzalez I believe I've addressed all open comments aside from https://github.com/jquery/jquery-wp-content/pull/391/files#r52310552, which is pending comments. Let me know if I missed anything.

Cheers! J

cc: @jdorfman

[jmervine]

@scottgonzalez All outstanding comments have been addressed as far as I can tell. Let me know if I missed anything or if there's anything else.

Cheers!

[jdorfman]

Let's :shipit:

[scottgonzalez]

It's finally live :-)

Thanks for all the work.

[jdorfman]

@scottgonzalez awesome! Thank you =)