For some reason the banner had hardcoded Arial font. Drop so that we
inherit our global Ubuntu font set on the <body>.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
We had an hardcoded mobile banner that was nice looking but couldn't
deal with all the content for the various banners we want to display.
Also, it was a separate element to the desktop one. Unify them as a
single element that adapts (as it should) to desktop or mobile
viewports.
Avoid many tiny requests. The issue is that browsers have a limited
amount of concurrent requests they can make. We do 19 for
loading /linux/v6.11.6/source. Reduce that to 14.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Pygments 2.12.0 slightly changed the order of HTML elements which
makes line numbers look weird with current CSS styles.
Quoting changelog:
> When linenos=table is used, the <table> itself is now wrapped
> with a <div class="highlight"> tag instead of placing it
> inside the <td class="code"> cell (#632.) With this change,
> the output matches the documented behavior.
https://pygments.org/docs/changelog/#version-2-12-0
Related issue: https://github.com/pygments/pygments/issues/632
This commit aims to fix this by further restricting CSS selectors
that selected everything under .highlight to only select source code
related elements - descendants of .code in the new layout.
This was also tested on Pygemnts 2.14.0, version currently packaged
for Debian Bookworm
https://packages.debian.org/bookworm/armel/python3-pygments
This parameter makes the server return a response with raw file
contents and headers that cause the browser to show a 'save as' dialog.
Regarding Content-Security-Policy:
https://www.w3.org/TR/CSP2/#sandbox-usage
> For example, a message board or email system might provide downloads of
> arbitrary attachments provided by other users. Attacks that rely on tricking
> a client into rendering one of these attachments could be mitigated by
> requesting that resources only be rendered in a very restrictive sandbox.
> Sending the sandbox directive with an empty value establishes such an
> environment:
>
> Content-Security-Policy: sandbox
https://www.w3.org/TR/CSP2/#directive-default-src
> Given this behavior, one good way of building a policy for a site would be to
> begin with a default-src of 'none', and to build up a policy from there that
> contains only those resource types which are actually in use for the page
> you’d like to protect. If you don’t use webfonts, for instance, there’s no
> reason to specify a source list for font-src; specifying only those resource
> types a page uses ensures that the possible attack surface for that page
> remains as small as possible.
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#defense-in-depth
> A strong CSP provides an effective second layer of protection against various
> types of vulnerabilities, especially XSS. Although CSP doesn't prevent web
> applications from containing vulnerabilities, it can make those
> vulnerabilities significantly more difficult for an attacker to exploit.
The idea is to prevent the browser from loading any external resources, if it
turned out it's possible to trick it into interpreting a file as HTML.
