host javascript libraries and let crates optionally load them in

[QuietMisdreavus]

There is a prominent group of crates that have used a trick to load in the KaTeX library to render equations in their docs. Previously, these crates have been able to point their doc process at a cached file when building that would load in an HTML file that sources the library. However, when we migrated the server last year, the cached file was lost, and new attempts to load a new cached file have failed to properly locate it.

Instead of tweaking folder permissions to allow the doc process to point at this hard-coded file, why don't we start hosting this library? We could add a new option to our metadata that people could use to specify a library (from a list of ones we've approved to start hosting), and then we would add the --html-in-header flag to the rustdoc call to splice in the required loads. (I would also like to start hosting the JS files themselves, so that would need to be tracked as well.) This way, the crates that need a specific library can use it, and we don't have to try to support the hard-coded paths that they've been using in the past. We could even add more stuff, like highlight-js or Highcharts or something else.

[hdevalence]

This would be really lovely (as a user of that "feature"), and it seems a lot better to allow crates to pull JS from a whitelisted library list than to do stored XSS on whatever they want.

[onur]

Some people actually managed to load their desired javascript files from their crate root but I can't remember name of the crate or how they did this, but I am sure it is currently possible to do that.

[jyn514]

We discussed today that hosting the JS isn't ideal because it means that either local builds have to be different from docs.rs builds, or that local builds have to load assets from the internet. I suggested instead special-casing known JS files (e.g. by their hash) which allows embedding them both locally and remotely.

[jsha]

I posted a comment at #167 (comment). Allowing JS files by hash only makes sense if we have a strong process for disallowing most JS. It also adds administrative burden for the docs.rs maintainers, as they would have to handle requests to add JS files and their hashes. Also, we would either need a very long CSP header to list all the hashes, or a per-release notion of which JS files are used.

As I understand it, the status quo is that third-party JS is not blocked on docs.rs. If we do want to make efforts to fully block it, I think those efforts should focus on using subdomains. If we use subdomains, each crate's JS execution context is isolated from each other crate's, so we can allow crates to include whatever JS they would like, without allowlisting.