tickets #38159
closedLook into adding these additional headers to download.o.o
Added by pjessen almost 6 years ago. Updated about 5 years ago.
100%
Description
cache control
content security policy
x content type
Strict http transport security
Updated by pjessen almost 6 years ago
- Subject changed from Look into using adding these additional headers to download.o.o to Look into adding these additional headers to download.o.o
- Private changed from Yes to No
Updated by pjessen almost 6 years ago
a) cache control
Currently, Mirrorbrain sets "Last-Modified" which leaves it to the browser to determine some reasonable cache time.
Typically, when the browser or webcache does not know if a resource has changed, it will issue a conditional GET, to which the server will respond with a "304 Not Modified" when the content hasn't changed. If the browser or webcache knows for certain that the cached content is still valid, it will not issue any GET.
I think it might make sense to set explicit cache times for the on-demand index listings produced by mirrorbrain, maybe for some of the non-mirrored files too. It would save quite a few requests on pontifex.
Grepping around in the logs, yesterday I see the following number of requests that got a 304:
/distribution - 17662
/tumbleweed - 8646
/repositories - 868612
/debug - 1297
/source - 1231
repositories/
home:/ - 505522
isv:/ - 205839
To be really useful, cache time should be set by directory as they vary a lot:
30 days:
distribution/
debug/distribution
source/distribution
24 hours?
update
debug/update
source/update
24 hours?
tumbleweed/
debug/tumbleweed
source/tumbleweed
ports/<arch>/<as above>
ports/<arch>/distribution/leap/<version>/appliances
ports/<arch>/distribution/leap/15.0/appliances - daily?
repositories ?
The individual packages (rpm, drpm) are not served by download.o.o, but other files are - e.g. .'mirrorlist.'
Updated by pjessen almost 6 years ago
b) Strict HTTP Transport Security
As we are serving download.o.o both as http and https, this is not possible.
c) Content-Security-Policy
I had to look this one up - it appears to be primarily about a policy governing where content may be fetched from.
On download.o.o, we don't refer to content elsewhere, so I suggest Content-Security-Policy: default-src 'self' opensuse.org should be sufficient.
d) X-Content-Type
I had to look this one up too. It looks like we can safely set X-Content-Type-Options: nosniff.
Updated by cboltz almost 6 years ago
c) Content-Security-Policy
[...]
On download.o.o, we don't refer to content elsewhere, so I suggest Content-Security-Policy: default-src 'self' opensuse.org should be sufficient.
I'm afraid reality disagrees - see ticket #38315 ;-)
Updated by pjessen almost 6 years ago
- Status changed from New to In Progress
- Assignee set to pjessen
Yeah, it looks like inline javascript is not permitted with the default policy. We should probably add "script-src: 'unsafe-inline'".
Updated by pjessen about 5 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
pjessen wrote:
Yeah, it looks like inline javascript is not permitted with the default policy. We should probably add "script-src: 'unsafe-inline'".
I'm adding this:
Header set Content-Security-Policy "default-src 'none'; img-src 'self'; style-src 'self'; script-src 'self' 'unsafe-inline'"
I am by no means an expert on this, but this seems to do what we need. If anyone has an issue with it, please reopen.
Testing this policy with e.g. https://csp-evaluator.withgoogle.com/ and it complains about the unsafe-inline.
Apparently, it is possible to avoid using 'unsafe-inline' - if anyone is interested, look up "csp script-src nonce" and feel free to propose how to implement it.