Should CDN example on Download documentation page contain Subresource Integrity info?

[hakanson]

https://docs.angularjs.org/misc/downloading which is sourced from downloading.ngdoc contains a "Including angular scripts from the Google CDN" section with this example for downloading from the Google CDN server:

<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.5/angular.min.js"></script>

With Subresource Integrity available in some browsers, should this example be updated to include an integrity attribute?

<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.5/angular.min.js"
        integrity="sha384-hXNI9Cb8OJC3+q10tEC7RUzaDEWKjIQiE1lg+tFIrttefIG+ScUCKqOlQVEqcmM0"
        crossorigin="anonymous"></script>

This value was determined by downloading the minified 1.4.5 file and computing the hash using:

wget https://ajax.googleapis.com/ajax/libs/angularjs/1.4.5/angular.min.js 
cat angular.min.js | openssl dgst -sha384 -binary | openssl enc -base64 -A

This is a good suggestion from a security perspective, but requires the documentation to be updated with a new integrity attribute along with every version change. It also would require the developer to understand the purpose of this attribute value, because if they copy that example and only change 1.4.5 to 1.4.6, the script will not load and the developer will get a potentially confusing error in the Console like:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://ajax.googleapis.com/ajax/libs/angularjs/1.4.6/angular.min.js' with computed SHA-256 integrity 'RIkiUZXLM0fYBgxgKBSCPnFxlu37oguHYe96c9t+HAg='. The resource has been blocked.

However, I would like to see the hashed for Subresource Integrity published somewhere, even if the Download documentation isn't the right place.

[petebacondarwin]

This sounds like an excellent idea. Although I am wondering if the safest path is to encourage people to use a published version. Isn't it better that a developer downloads a copy of the library, checks that it is valid and then generates their own SRI? That way they know for sure what content they are receiving.

[hakanson]

I agree it is best to download a copy and serve it yourself. However, many tutorials reference a CDN and if you use the Google CDN it is likely the browser gets a cache hit.

I was brainstorming that on every "release" (e.g. 1.4.9, 1.5.0, 1.5.1, etc), the integrity hash values could be generated and put into a SRI.json file. Those values could be used to both feed the documentation and used as input into a grunt/gulp/whatever build task for projects using angular.js to add the integrity attribute to script tags.

I'm not sure of the best solution, nor know of other libraries to look at as examples, but wanted to raise as an issue for the discussion on what to do.

[ScottHelme]

I'm not sure that I agree it's better to host your own copy as that can result in a worse experience for the user in a few ways. Using an asset from a CDN increases the chance that the user will already have it in their cache, reducing bandwidth requirements and potentially cost. This also improves performance which results in a better UX. SRI resolves the trust issue of allowing a 3rd party to serve your assets.

Many projects already provide checksum/integrity values for their downloads and SRI is, in effect, a method of automating that process in the browser. If we can't trust the integrity values provided by the project then we have greater concerns. Also, is a developer realistically going to review the entire Angular code base before generating their own integrity value?

The only addition I'd make here is that the provided script tags for each release should include more than the sha384 integrity value. A browser will always chose the strongest hash that it supports so it could be a good idea to include the sha256 and sha512 values for backwards and forwards compatibility too. As Kevin mentioned, there are simple methods to produce these values and include them in documentation for wider circulation.

[petebacondarwin]

I wasn't suggesting that one hosts their own copy. I was just saying that if you can't rely upon the CDN being valid then why should you rely upon us providing a valid hash? I was suggesting that you use the CDN but then generate your own hash from a copy downloaded from the CDN that you have confirmed is valid.

[petebacondarwin]

We will discuss this in the team meeting today and come up with a plan.

[ScottHelme]

Ok, self hosting aside as that seems to have taken us off topic, we still need to depend on you guys to provide the hash.

If we download a copy from a CDN where and how do we validate that? We're going to turn to you guys and say 'is this valid?'. That's exactly what integrity hashes are for, both in the context of SRI and otherwise. You as the author define the hash that all others are checked against. Failing that I'm not sure what other method we have to validate the file.

[petebacondarwin]

OK, so we discussed this in our team meeting. Here is the plan:

• add the hash for the core angular.min.js to the download button on https://angularjs.org
• when we build a release, generate a text file contain a hash for each of our distribution files (i.e. each module's .js and .min.js file) and place these files in the appropriate folder on https://code.angularjs.org
• add some documentation explaining what these files are and what to do with them

Is this acceptable?
PRs are most welcome :-)