Fossil

Check-in [3f49a849]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:EDITED www/server.wiki fixed formating and created ticket (I don't see the ticket in commit)
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | ttmrichter-skins
Files: files | file ages | folders
SHA1:3f49a849954f0fb8c5c19cf3e80722c5efb74284
User & Date: navratil 2010-10-08 17:08:13
Context
2010-11-07
10:23
Merge from trunk. Leaf check-in: 1a6876db user: michael tags: ttmrichter-skins
2010-10-08
17:08
EDITED www/server.wiki fixed formating and created ticket (I don't see the ticket in commit) check-in: 3f49a849 user: navratil tags: ttmrichter-skins
2010-10-05
14:40
Merge from trunk. check-in: 029448a3 user: michael tags: ttmrichter-skins
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/server.wiki.

92
93
94
95
96
97
98
99



100
101
102
103
104

105
106
107
108
109
110
111
112
113
114
115
If you are using "inetd" to serve your repository, then you simply need to add "/usr/bin/stunnel" (perhaps on a different path, depending on your setup) before the command line to launch Fossil.
</p>
<p>
At this stage, the standalone server (e.g. "fossil server") does not support SSL.
</p>
</blockquote>

<h2>Various security concerns with hosted repositories</h2><blockquote>



<p>
There are two main concerns relating to usage of Fossil for sharing sensitive information (source or any other data):
<ul>
<li>Interception of the Fossil synchronization stream, thereby capturing data, and
</ul>Direct access to the Fossil repository on the server

</p>
<p>
Regarding the first, it is adequate to secure the server using SSL, and disallowing any non-SSL access.  The data stream will be encrypted by the HTTPS protocol, rendering the data reasonably secure.  The truly paranoid may wish to deploy <i>ssh</i> encrypted tunnels, but that is quite a bit more difficult and cumbersome to set up (particularly for a larger number of users).
</p>
<p>
As far as direct access to the repository, the same steps must be taken as for any other internet-facing data-store.  Access passwords to any disk-accessing accounts should be strong (and preferably changed from time to time).  However, the data in the repository itself are <i>not</i> encrypted (unless you save encrypted data yourself), and so the system administrators of your server will be able to access your data (as with any hosting service setup).  The only workaround in this case is to host the server yourself, in which case you will need to allocate resources to deal with administration issues.
</p>

</blockquote>

</nowiki>







|
>
>
>




|
>











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
If you are using "inetd" to serve your repository, then you simply need to add "/usr/bin/stunnel" (perhaps on a different path, depending on your setup) before the command line to launch Fossil.
</p>
<p>
At this stage, the standalone server (e.g. "fossil server") does not support SSL.
</p>
</blockquote>

<h2>Various security concerns with hosted repositories</h2>

<blockquote>

<p>
There are two main concerns relating to usage of Fossil for sharing sensitive information (source or any other data):
<ul>
<li>Interception of the Fossil synchronization stream, thereby capturing data, and
<li>Direct access to the Fossil repository on the server
</ul>
</p>
<p>
Regarding the first, it is adequate to secure the server using SSL, and disallowing any non-SSL access.  The data stream will be encrypted by the HTTPS protocol, rendering the data reasonably secure.  The truly paranoid may wish to deploy <i>ssh</i> encrypted tunnels, but that is quite a bit more difficult and cumbersome to set up (particularly for a larger number of users).
</p>
<p>
As far as direct access to the repository, the same steps must be taken as for any other internet-facing data-store.  Access passwords to any disk-accessing accounts should be strong (and preferably changed from time to time).  However, the data in the repository itself are <i>not</i> encrypted (unless you save encrypted data yourself), and so the system administrators of your server will be able to access your data (as with any hosting service setup).  The only workaround in this case is to host the server yourself, in which case you will need to allocate resources to deal with administration issues.
</p>

</blockquote>

</nowiki>