[v2] docs/website: consolidate CDN's and enable SRI

From: James Hilliard <james.hilliard1@gmail.com>

Some of our cdn's are going discontinued (rawgit) and some others are
not recommended anymore, thus we update to the recommended cdnjs.
This patch enables also SRI protection on js to be sure the modules we
download are not manipulated in any way.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
---
[v1 -> v2]:
* Fixing wrong CDN for bootswatch
* Fixing commit message

 docs/website/footer.html | 6 +++---
 docs/website/header.html | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

>>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:

 > From: James Hilliard <james.hilliard1@gmail.com>
 > Some of our cdn's are going discontinued (rawgit) and some others are
 > not recommended anymore, thus we update to the recommended cdnjs.
 > This patch enables also SRI protection on js to be sure the modules we
 > download are not manipulated in any way.

It would be great for people not doing web things (E.G. me) to add the

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

to explain what SRI is.

The files we get from these CDNs are not that big, E.G:

-rw-r--r--  1 peko peko 139K May 17  2018 bootstrap.min.css
-rw-r--r--  1 peko peko  37K May 17  2018 bootstrap.min.js
-rw-r--r--  1 peko peko 2.4K May 17  2018 html5shiv.js
-rw-r--r--  1 peko peko  85K May 17  2018 jquery.min.js
-rw-r--r--  1 peko peko 4.0K May 17  2018 respond.min.js

Does it make sense to use those CDNs that we don't have under our
control, or should we just commit these files?

On Mon, Feb 4, 2019 at 1:35 PM Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:
>
>  > From: James Hilliard <james.hilliard1@gmail.com>
>  > Some of our cdn's are going discontinued (rawgit) and some others are
>  > not recommended anymore, thus we update to the recommended cdnjs.
>  > This patch enables also SRI protection on js to be sure the modules we
>  > download are not manipulated in any way.
>
> It would be great for people not doing web things (E.G. me) to add the
>
> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
>
> to explain what SRI is.
>
> The files we get from these CDNs are not that big, E.G:
>
> -rw-r--r--  1 peko peko 139K May 17  2018 bootstrap.min.css
> -rw-r--r--  1 peko peko  37K May 17  2018 bootstrap.min.js
> -rw-r--r--  1 peko peko 2.4K May 17  2018 html5shiv.js
> -rw-r--r--  1 peko peko  85K May 17  2018 jquery.min.js
> -rw-r--r--  1 peko peko 4.0K May 17  2018 respond.min.js
>
> Does it make sense to use those CDNs that we don't have under our
> control, or should we just commit these files?

Hosting these files by themselves means serving them by our webserver,
this is usually costly and bandwidth consuming.

Moreover, saving a compressed javascript in git it's not recommended
because their somewhat like binary files.

Again, updating them is quite annoying cause instead of simply
updating a line in a javascript file, we should replace the compressed
js file.

>
> --
> Bye, Peter Korsgaard

On Mon, Feb 4, 2019 at 3:17 AM Angelo Compagnucci
<angelo@amarulasolutions.com> wrote:
>
> From: James Hilliard <james.hilliard1@gmail.com>
>
> Some of our cdn's are going discontinued (rawgit) and some others are
> not recommended anymore, thus we update to the recommended cdnjs.
> This patch enables also SRI protection on js to be sure the modules we
> download are not manipulated in any way.
>
> Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
> ---
> [v1 -> v2]:
> * Fixing wrong CDN for bootswatch
> * Fixing commit message
>
>  docs/website/footer.html | 6 +++---
>  docs/website/header.html | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/docs/website/footer.html b/docs/website/footer.html
> index 2811fc5..5b18047 100644
> --- a/docs/website/footer.html
> +++ b/docs/website/footer.html
> @@ -1,6 +1,6 @@
> -       <script src="https://code.jquery.com/jquery-3.1.1.min.js"></script>
> -       <script src="https://oss.maxcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
> -       <script src="https://cdn.rawgit.com/zenorocha/clipboard.js/v1.7.1/dist/clipboard.min.js"></script>
> +       <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.min.js" integrity="sha256-hVVnYaiADRTO2PzUGmuLJr8BLUSjGIZsDYGmIJLv2b8=" crossorigin="anonymous"></script>
> +       <script src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha256-U5ZEeKfGNOja007MMD3YBI0A3OSZOQbeG6z2f2Y0hu8=" crossorigin="anonymous"></script>
> +       <script src="https://cdnjs.cloudflare.com/ajax/libs/clipboard.js/1.7.1/clipboard.min.js" integrity="sha256-Daf8GuI2eLKHJlOWLRR/zRy9Clqcj4TUSumbxYH9kGI=" crossorigin="anonymous"></script>
>         <script type="text/javascript" src="js/buildroot.js"></script>
>  </body>
>  </html>
> diff --git a/docs/website/header.html b/docs/website/header.html
> index ef6724f..f09c232 100644
> --- a/docs/website/header.html
> +++ b/docs/website/header.html
> @@ -10,12 +10,12 @@
>
>         <title>Buildroot - Making Embedded Linux Easy</title>
>
> -       <link href="https://oss.maxcdn.com/bootswatch/3.3.7/paper/bootstrap.min.css" rel="stylesheet">
> +       <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootswatch/3.3.7/paper/bootstrap.min.css" integrity="sha384-awusxf8AUojygHf2+joICySzB780jVvQaVCAt1clU3QsyAitLGul28Qxb2r1e5g+" crossorigin="anonymous">
I think this should be this since the other tags use sha256 SRI:
<link rel="stylesheet"
href="https://cdnjs.cloudflare.com/ajax/libs/bootswatch/3.3.7/paper/bootstrap.min.css"
integrity="sha256-LxKiHTQko0DUCUSgrIK23SYMymvfuj8uxXmblBvVWm0="
crossorigin="anonymous" />
>         <link href="css/main.css" rel="stylesheet">
>
>         <!--[if lt IE 9]>
> -         <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
> -         <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
> +         <script src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.0/html5shiv.js" integrity="sha256-jHqcBHBWM2erADB7T7m7MFLQon8LlOY7ncC7jDaUScs=" crossorigin="anonymous"></script>
> +         <script src="https://cdnjs.cloudflare.com/ajax/libs/respond.js/1.3.0/respond.min.js" integrity="sha256-g2lnLPqUkGXj7GDW+Zy47+O2ph+Ur1cmtdklVqkj+kg=" crossorigin="anonymous"></script>
>         <![endif]-->
>  </head>
>
> --
> 2.7.4
>

>>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:

 > On Mon, Feb 4, 2019 at 1:35 PM Peter Korsgaard <peter@korsgaard.com> wrote:
 >> 
 >> >>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:
 >> 
 >> > From: James Hilliard <james.hilliard1@gmail.com>
 >> > Some of our cdn's are going discontinued (rawgit) and some others are
 >> > not recommended anymore, thus we update to the recommended cdnjs.
 >> > This patch enables also SRI protection on js to be sure the modules we
 >> > download are not manipulated in any way.
 >> 
 >> It would be great for people not doing web things (E.G. me) to add the
 >> 
 >> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
 >> 
 >> to explain what SRI is.
 >> 
 >> The files we get from these CDNs are not that big, E.G:
 >> 
 >> -rw-r--r--  1 peko peko 139K May 17  2018 bootstrap.min.css
 >> -rw-r--r--  1 peko peko  37K May 17  2018 bootstrap.min.js
 >> -rw-r--r--  1 peko peko 2.4K May 17  2018 html5shiv.js
 >> -rw-r--r--  1 peko peko  85K May 17  2018 jquery.min.js
 >> -rw-r--r--  1 peko peko 4.0K May 17  2018 respond.min.js
 >> 
 >> Does it make sense to use those CDNs that we don't have under our
 >> control, or should we just commit these files?

 > Hosting these files by themselves means serving them by our webserver,
 > this is usually costly and bandwidth consuming.

Yes, but given their small size, this is probably not a huge concern?
E.G. news.html is ~200KB.

 > Moreover, saving a compressed javascript in git it's not recommended
 > because their somewhat like binary files.

Correct, but we already have the website images in it as well. Given
that these things only rarely change, I don't think that is a big
concern.

 > Again, updating them is quite annoying cause instead of simply
 > updating a line in a javascript file, we should replace the compressed
 > js file.

Is is still a single commit, either changing the the version + hash.

On Mon, Feb 4, 2019 at 2:57 PM Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:
>
>  > On Mon, Feb 4, 2019 at 1:35 PM Peter Korsgaard <peter@korsgaard.com> wrote:
>  >>
>  >> >>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:
>  >>
>  >> > From: James Hilliard <james.hilliard1@gmail.com>
>  >> > Some of our cdn's are going discontinued (rawgit) and some others are
>  >> > not recommended anymore, thus we update to the recommended cdnjs.
>  >> > This patch enables also SRI protection on js to be sure the modules we
>  >> > download are not manipulated in any way.
>  >>
>  >> It would be great for people not doing web things (E.G. me) to add the
>  >>
>  >> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
>  >>
>  >> to explain what SRI is.
>  >>
>  >> The files we get from these CDNs are not that big, E.G:
>  >>
>  >> -rw-r--r--  1 peko peko 139K May 17  2018 bootstrap.min.css
>  >> -rw-r--r--  1 peko peko  37K May 17  2018 bootstrap.min.js
>  >> -rw-r--r--  1 peko peko 2.4K May 17  2018 html5shiv.js
>  >> -rw-r--r--  1 peko peko  85K May 17  2018 jquery.min.js
>  >> -rw-r--r--  1 peko peko 4.0K May 17  2018 respond.min.js
>  >>
>  >> Does it make sense to use those CDNs that we don't have under our
>  >> control, or should we just commit these files?
>
>  > Hosting these files by themselves means serving them by our webserver,
>  > this is usually costly and bandwidth consuming.
>
> Yes, but given their small size, this is probably not a huge concern?
> E.G. news.html is ~200KB.

Yes, I know, in an optimistic world we could have that page sliced on
smaller chunks and retrieved one chunk at a time.
It could be done, but I don't know how much that page is visited.
I don't know if we have a proper network load statistics to understand
if this could be a valuable work to do.

>  > Moreover, saving a compressed javascript in git it's not recommended
>  > because their somewhat like binary files.
>
> Correct, but we already have the website images in it as well. Given
> that these things only rarely change, I don't think that is a big
> concern.

Yes I know, but unless we pay to host on a CDN ourselves, we can't do otherwise.
I think that something could be optimized from a size point of view.

I think if we can save some some bandwidth, we should go that route,
but if costs are not a main concern, we can opt to have everything on
local server.


>  > Again, updating them is quite annoying cause instead of simply
>  > updating a line in a javascript file, we should replace the compressed
>  > js file.
>
> Is is still a single commit, either changing the the version + hash.
>
> --
> Bye, Peter Korsgaard

>>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:

Hi,

 >> Yes, but given their small size, this is probably not a huge concern?
 >> E.G. news.html is ~200KB.

 > Yes, I know, in an optimistic world we could have that page sliced on
 > smaller chunks and retrieved one chunk at a time.
 > It could be done, but I don't know how much that page is visited.
 > I don't know if we have a proper network load statistics to understand
 > if this could be a valuable work to do.

We afaik don't really have any data. We used to have Google analytics on
the website, but it seems to be broken.


 >> > Moreover, saving a compressed javascript in git it's not recommended
 >> > because their somewhat like binary files.
 >> 
 >> Correct, but we already have the website images in it as well. Given
 >> that these things only rarely change, I don't think that is a big
 >> concern.

 > Yes I know, but unless we pay to host on a CDN ourselves, we can't do
 > otherwise.  I think that something could be optimized from a size
 > point of view.

 > I think if we can save some some bandwidth, we should go that route,
 > but if costs are not a main concern, we can opt to have everything on
 > local server.

We don't directly pay for bandwidth (osuosl.org does), and I seriously
doubt it is significant compared to sources.buildroot.org (~1.5TB/month).

On Mon, Feb 4, 2019 at 7:13 PM Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:
>
> Hi,
>
>  >> Yes, but given their small size, this is probably not a huge concern?
>  >> E.G. news.html is ~200KB.
>
>  > Yes, I know, in an optimistic world we could have that page sliced on
>  > smaller chunks and retrieved one chunk at a time.
>  > It could be done, but I don't know how much that page is visited.
>  > I don't know if we have a proper network load statistics to understand
>  > if this could be a valuable work to do.
>
> We afaik don't really have any data. We used to have Google analytics on
> the website, but it seems to be broken.
>
>
>  >> > Moreover, saving a compressed javascript in git it's not recommended
>  >> > because their somewhat like binary files.
>  >>
>  >> Correct, but we already have the website images in it as well. Given
>  >> that these things only rarely change, I don't think that is a big
>  >> concern.
>
>  > Yes I know, but unless we pay to host on a CDN ourselves, we can't do
>  > otherwise.  I think that something could be optimized from a size
>  > point of view.
>
>  > I think if we can save some some bandwidth, we should go that route,
>  > but if costs are not a main concern, we can opt to have everything on
>  > local server.
>
> We don't directly pay for bandwidth (osuosl.org does), and I seriously
> doubt it is significant compared to sources.buildroot.org (~1.5TB/month).

So no problem!

I'll have a look at why google analytics doesn't work anymore.

>
> --
> Bye, Peter Korsgaard

On Mon, Feb 4, 2019 at 7:11 AM Angelo Compagnucci
<angelo@amarulasolutions.com> wrote:
>
> On Mon, Feb 4, 2019 at 2:57 PM Peter Korsgaard <peter@korsgaard.com> wrote:
> >
> > >>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:
> >
> >  > On Mon, Feb 4, 2019 at 1:35 PM Peter Korsgaard <peter@korsgaard.com> wrote:
> >  >>
> >  >> >>>>> "Angelo" == Angelo Compagnucci <angelo@amarulasolutions.com> writes:
> >  >>
> >  >> > From: James Hilliard <james.hilliard1@gmail.com>
> >  >> > Some of our cdn's are going discontinued (rawgit) and some others are
> >  >> > not recommended anymore, thus we update to the recommended cdnjs.
> >  >> > This patch enables also SRI protection on js to be sure the modules we
> >  >> > download are not manipulated in any way.
> >  >>
> >  >> It would be great for people not doing web things (E.G. me) to add the
> >  >>
> >  >> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
> >  >>
> >  >> to explain what SRI is.
> >  >>
> >  >> The files we get from these CDNs are not that big, E.G:
> >  >>
> >  >> -rw-r--r--  1 peko peko 139K May 17  2018 bootstrap.min.css
> >  >> -rw-r--r--  1 peko peko  37K May 17  2018 bootstrap.min.js
> >  >> -rw-r--r--  1 peko peko 2.4K May 17  2018 html5shiv.js
> >  >> -rw-r--r--  1 peko peko  85K May 17  2018 jquery.min.js
> >  >> -rw-r--r--  1 peko peko 4.0K May 17  2018 respond.min.js
> >  >>
> >  >> Does it make sense to use those CDNs that we don't have under our
> >  >> control, or should we just commit these files?
> >
> >  > Hosting these files by themselves means serving them by our webserver,
> >  > this is usually costly and bandwidth consuming.
> >
> > Yes, but given their small size, this is probably not a huge concern?
> > E.G. news.html is ~200KB.
>
> Yes, I know, in an optimistic world we could have that page sliced on
> smaller chunks and retrieved one chunk at a time.
> It could be done, but I don't know how much that page is visited.
> I don't know if we have a proper network load statistics to understand
> if this could be a valuable work to do.
>
> >  > Moreover, saving a compressed javascript in git it's not recommended
> >  > because their somewhat like binary files.
> >
> > Correct, but we already have the website images in it as well. Given
> > that these things only rarely change, I don't think that is a big
> > concern.
>
> Yes I know, but unless we pay to host on a CDN ourselves, we can't do otherwise.
> I think that something could be optimized from a size point of view.
>
> I think if we can save some some bandwidth, we should go that route,
> but if costs are not a main concern, we can opt to have everything on
> local server.
I would recommend sticking with a CDN, I chose the Cloudflare one
since it's unlikely to go anywhere(unlike smaller CDN's like rawgit)
and has all the assets we use.
Using a CDN can speed up performance due to browsers caching assets
across different sites from my understanding.
>
>
> >  > Again, updating them is quite annoying cause instead of simply
> >  > updating a line in a javascript file, we should replace the compressed
> >  > js file.
> >
> > Is is still a single commit, either changing the the version + hash.
> >
> > --
> > Bye, Peter Korsgaard

On 04/02/2019 23:30, James Hilliard wrote:
> Using a CDN can speed up performance due to browsers caching assets
> across different sites from my understanding.

 Indeed, I think that is the main reason to use a CDN:

1. It is likely to be cached already on the browser, and
2. It avoids that the driver needs to open connections to various site, it can
just open one (HTTP/2 or /3) connection do the CDN if it really does need to get
the stuff.

 That said, since these files are tiny, it's probably not important (definitely
not important enough to bikeshed over :-). The SRI, on the other hand, *is*
important IMO.

 Regards,
 Arnout

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 > On 04/02/2019 23:30, James Hilliard wrote:
 >> Using a CDN can speed up performance due to browsers caching assets
 >> across different sites from my understanding.

 >  Indeed, I think that is the main reason to use a CDN:

 > 1. It is likely to be cached already on the browser, and
 > 2. It avoids that the driver needs to open connections to various site, it can
 > just open one (HTTP/2 or /3) connection do the CDN if it really does need to get
 > the stuff.

 >  That said, since these files are tiny, it's probably not important (definitely
 > not important enough to bikeshed over :-).

Agreed.

 > The SRI, on the other hand, *is* important IMO.

Agreed, if we refer to ressources out of our control we should
definately use SRI.