Fossil

Diff
Login

Diff

Annotate Patch Side-by-side Diff

Differences From Artifact [9707510681]:

To Artifact [85d32e367b]:

︙
47
48
49
50
51
52
53
54
55
56



57
58
59



60
61
62
63
64
65
66
67
68
69
70




71


72
73
74









75
76
77


78
79
80
81
82
83
84




























85
86
87
88
89
90
91

47
48
49
50
51
52
53



54
55
56

57
58
59
60
61
62
63
64
65
66
67
68
69



70
71
72
73
74
75
76



77
78
79
80
81
82
83
84
85
86
87
88
89
90







91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125








-
-
-
+
+
+
-


+
+
+








-
-
-
+
+
+
+

+
+
-
-
-
+
+
+
+
+
+
+
+
+



+
+
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+








## The Default Restrictions

The Fossil default CSP declares the following content restrictions:


### <a name="base"></a> default-src 'self' data:

This policy means mixed-origin content isn’t allowed, so you can’t refer to
resources (images, style-sheets, and scripts) on other web domains.
Hence the following Markdown for an inline
This policy means mixed-origin content isn’t allowed, so you can’t refer
to resources on other web domains. Browsers will ignore a link like the
one in the following Markdown under our default CSP:
image hosted on another site will cause a CSP error:

         ![fancy 3D Fossil logotype](https://i.imgur.com/HalpMgt.png)

If you look in the browser’s developer console, you should see a CSP
error when attempting to render such a page.

The default policy does allows inline `data:` URIs, which means you could
[data-encode][de] your image content and put it inline within the
document:

         ![small inline image](data:image/gif;base64,R0lGODlh...)

That method is best used for fairly small resources. Large `data:` URIs
are hard to read and edit. Keep in mind that if you put such a thing
into a Fossil forum post, anyone subscribed to email alerts will get a
copy of the raw URI text, which is really ugly.
are hard to read and edit. There are secondary problems as well: if you
put a large image into a Fossil forum post this way, anyone subscribed
to email alerts will get a copy of the raw URI text, which can amount to
pages and pages of [ugly Base64-encoded text][b64].

Fossil offers several alternatives for serving large content resources
from within the repository:
For larger images in [embedded documentation](./embeddeddoc.wiki) you
store the image as a separate file in the Fossil repository and reference
it via a relative URI.

*   **versioned content** via [`/raw`](/help?cmd=/raw)
*   **[unversioned content](./unvers.wiki)** via [`/uv`](/help?cmd=/uv)
*   **relative links**

Only the first two options work in [wiki articles][wiki],
[tickets][tkt], [forum posts][fp], and [tech notes][tn].  The last
option is a much simpler alternative, but it only works within [embedded
documentation][ed]:

         ![large inline image](./inlineimage.jpg)

Because all of these methods pull content from within the Fossil
repository, they all count as “self” for the purposes of the CSP.
Any content from the same domain as the Fossil repository will work fine.
So if the Fossil repository is but one path in a larger website, it will
be able reference other static resources within that same website.  It
can also reference [unversioned content](./unvers.wiki).  However, as
unversioned content and content outside of the Fossil repository itself
will not be transferred by [sync](/help?cmd=sync), the references probably
will not work in clones of your repository.

This rule also works when the Fossil repository is but one path in a
larger website. The browser can’t distinguish Fossil-served content from
that served by the rest of the same web domain, so your repository can
refer to other resources within that same web site, whether they are
static files served by [an HTTP proxy in front of Fossil][svr], by
another Fossil repository served under that same domain, or dynamic
content served by, say, a PHP app on that same site.

Beware that there are a number of problems that come up with using such
out-of-repository resources, which all stem from the fact that they
aren’t included in a [sync](/help?cmd=sync):

1.  Relative links break in `fossil ui` when run on a clone.

2.  Absolute links break under certain types of failover and
    load-balancing schemes.

3.  Absolute links fail when one’s purpose in using a clone is to
    recover from the loss of a project web site by standing that clone
    up [as a server][svr] elsewhere.

You can avoid all of these problems by referring to in-repo resources
exclusively.

[b64]: https://en.wikipedia.org/wiki/Base64
[svr]: ./server/


### <a name="style"></a> style-src 'self' 'unsafe-inline'

This policy allows CSS information to come from separate files in the
same domain of the Fossil server, or for CSS to be embedded inline within
the document text.
︙
102
103
104
105
106
107
108
109

110
111
112
113
114
115
116

136
137
138
139
140
141
142

143
144
145
146
147
148
149
150








-
+








This policy disables in-line javascript and only allows `<script>`
elements if the `<script>` includes a `nonce=` attribute the
matches the %s section of the CSP.  Fossil provides a different
random nonce for every page it generates, and since an attacker has
no way of predicting what that nonce will be, the attacker is unable
to inject working javascript.

For documents generated by the [CGI extensions](./serverext.wiki), the
For documents generated by the [CGI extensions][ext], the
value of the nonce is accessible in the FOSSIL_NONCE environment variable.
TH1 scripts that run while generating the header or footer can access
the nonce in the $nonce variable.  The JavaScript section of a
[custom skin][cs] automatically includes the appropriate nonce.

#### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities
︙
165
166
167
168
169
170
171

172
173
174
175
176
177
178

199
200
201
202
203
204
205
206
207
208
209
210
211
212
213








+








JavaScript but not those allowed to file tickets, append to wiki
articles, etc., you might justify enabling TH1 docs on your repository,
since the only way to create or modify HTML-formatted embedded docs is
through check-ins.

[ed]:   ./embeddeddoc.wiki
[edtf]: ./embeddeddoc.wiki#th1
[ext]:  ./serverext.wiki
[fp]:   ./forum.wiki
[hfed]: ./embeddeddoc.wiki#html
[tkt]:  ./tickets.wiki
[tn]:   ./event.wiki
[wiki]: ./wikitheory.wiki

## <a name="override"></a>Replacing the Default CSP
︙
230
231
232
233
234
235
236
237

238
239
240
241
242
243
244
245
246
247
248

249
250
251
252
253
254
255

265
266
267
268
269
270
271

272
273
274
275
276
277
278
279
280
281
282

283
284
285
286
287
288
289
290








-
+










-
+








instead as described in the custom skinning guide. Alternately, you can
[make use of `$default_csp`](#th1).

This then tells you one way to override Fossil’s default CSP: provide
your own HTML header in a custom skin.

A useful combination is to entirely override the default CSP in the skin
but then provide a new CSP [in the front-end proxy layer](./server/)
but then provide a new CSP [in the front-end proxy layer][svr]
using any of the many reverse proxy servers that can define custom HTTP
headers.


------------


**Asides and Digressions:**

1.  There is actually a third context that can correctly insert this
    nonce attribute: [a CGI server extension](./serverext.wiki), by use of
    nonce attribute: [a CGI server extension][ext], by use of
    the `FOSSIL_NONCE` variable sent to the CGI by Fossil.

2.  The stock Bootstrap skin does actually include a `<head>` tag, but
    from Fossil 2.7 through Fossil 2.9, it just repeated the same CSP
    text that Fossil’s C code inserts into the HTML header for all other
    stock skins. With Fossil 2.10, the stock Bootstrap skin uses
    `$default_csp` instead, so you can [override it as above](#th1).
︙