Content-Security-Policy on sourceware.org breaking HTML manuals

Content-Security-Policy on sourceware.org breaking HTML manuals

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

tl;dr: can we add "; style-src 'unsafe-inline' http: https:" to sourceware.org's CSP header ?

it seems a CSP header has been added to the sourceware.org web server at
some point and it breaks inline <style> in web pages.  it breaks inline
<script> too, but that's prob for the best, and i'm not aware of cases
that are affected by this.

$ curl --HEAD https://sourceware.org/
HTTP/2 200
date: Mon, 25 Dec 2023 01:03:04 GMT
server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_qos/11.74 mod_wsgi/4.6.4 Python/3.6 mod_perl/2.0.12 Perl/v5.26.3
accept-ranges: bytes
vary: Accept-Encoding
content-security-policy: default-src 'self' http: https:
strict-transport-security: max-age=16070400
content-type: text/html; charset=UTF-8

unfortunately, inline <style> is used in all HTML manuals generated by
GNU texinfo.  you can see this by visiting the GDB manual:
	https://sourceware.org/gdb/current/onlinedocs/gdb.html/

Chrome's devtools will show the warning:
> Refused to apply inline style because it violates the following Content Security Policy directive:
> "default-src 'self' http: https:". Either the 'unsafe-inline' keyword, a hash ('...'), or a
> nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not
> explicitly set, so 'default-src' is used as a fallback.

should we allow inline <style> for now on sourceware.org until we figure
out something better ?  i think it would just be:
	default-src 'self' http: https:; style-src 'unsafe-inline' http: https:

i grok that this disables one XSS protection, but i suspect its not a huge
concern for us ... we have bugzilla & wiki which hosts user-submitted content,
but the wiki at least is "trusted" devs, and bugzilla is normally programmed
with this stuff in mind.

a lot of these manuals are historical and would need manual regeneration
or hacking to use an external sheet.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Content-Security-Policy on sourceware.org breaking HTML manuals

[Frank Ch. Eigler]

Hi -

> tl;dr: can we add "; style-src 'unsafe-inline' http: https:" to
> sourceware.org's CSP header ?

There are a couple of ways in which this can be configured.  For
example, if you identify a URL location hierarchy where this would
help, we can add it to the whitelist in sourceware-GENERAL.conf L32.

- FChE

Re: Content-Security-Policy on sourceware.org breaking HTML manuals

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On 24 Dec 2023 20:22, Frank Ch. Eigler wrote:
> > tl;dr: can we add "; style-src 'unsafe-inline' http: https:" to
> > sourceware.org's CSP header ?
> 
> There are a couple of ways in which this can be configured.  For
> example, if you identify a URL location hierarchy where this would
> help, we can add it to the whitelist in sourceware-GENERAL.conf L32.

unfortunately, projects don't seem to be consistent here.  maybe if we
declared a rule like **/manual/** would allow inline csp, we could get
people to harmonize on a common layout (and leave symlinks for the old
paths so we don't break people).

quick survey of some projects ...

binutils: https://sourceware.org/binutils/docs*/**
bzip2:    https://sourceware.org/bzip2/manual/**
cgen:     https://sourceware.org/cgen/docs*/**
gdb:      https://sourceware.org/gdb/current/onlinedocs/**
glibc:    https://sourceware.org/glibc/manual/**
newlib:   https://sourceware.org/newlib/lib*.html
          (although i'm trying to change newlib to a manual/** system)
psim:     https://sourceware.org/psim/manual/** 
sid:      https://sourceware.org/sid/**
sim:      https://sourceware.org/gdb/sim/manual/**
          (i haven't published this yet)
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Content-Security-Policy on sourceware.org breaking HTML manuals

[Frank Ch. Eigler]

Hi -

> [...] unfortunately, projects don't seem to be consistent here.  [...]

Oh what a pity.

https://content-security-policy.com/unsafe-inline/
"The unsafe-inline keyword annuls most of the security benefits that
Content-Security-Policy provide."

Well, let me try adding some docs/manuals URL patterns.  But maybe we
will need to bite the bullet and disable this gadget entirely.

- FChE

Re: Content-Security-Policy on sourceware.org breaking HTML manuals

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On 25 Dec 2023 04:28, Frank Ch. Eigler wrote:
> > [...] unfortunately, projects don't seem to be consistent here.  [...]
> 
> Oh what a pity.
> 
> https://content-security-policy.com/unsafe-inline/
> "The unsafe-inline keyword annuls most of the security benefits that
> Content-Security-Policy provide."

i noted this in my initial posting, but i don't think it's this dire.
pretty sure it isn't relevant to our static pages, only when there's
dynamic content that is possibly coming from users.  with that in mind ...

> Well, let me try adding some docs/manuals URL patterns.  But maybe we
> will need to bite the bullet and disable this gadget entirely.

at the very least, we could invert it.  i'm not familiar with what all is
hosted on sourceware.org, but the major things that involve user input can
all be easily matched.  so we can keep the strict CSP for them, but relax
it for everyone else.
	/bugzilla/*  -- the bugzilla instance
	*/wiki/*     -- every project's wiki
	/mailman/*   -- list archives & form/acct management

are there any other major services ?

although i think enforcing */manual/* on projects if they want to host
texinfo-generated manuals is reasonable, and aligns with gnu.org layouts.
shouldn't be hard</lastwords> to drop compat symlinks for projects who
aren't already doing this.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]