Fossil SCM
Fix typos in the "Server" documentation. Also remove the "Security Considerations" paragraph at the end, which seems to be mostly common-sense.
Commit
dd357f7f064a6c03b3b79e255de6c654bb33cc5b
Parent
1c40de184393c82…
1 file changed
+5
-35
+5
-35
| --- www/server.wiki | ||
| +++ www/server.wiki | ||
| @@ -40,11 +40,11 @@ | ||
| 40 | 40 | to the URL mentioned above, and "ui" command binds to |
| 41 | 41 | the loopback IP address (127.0.0.1) only so that the "ui" command cannot be |
| 42 | 42 | used to serve content to a different machine. |
| 43 | 43 | </p> |
| 44 | 44 | <p> |
| 45 | -If one of the commands above is run from within an option checkout, | |
| 45 | +If one of the commands above is run from within an open checkout, | |
| 46 | 46 | then the <i>REPOSITORY</i> argument can be omitted and the checkout is used as |
| 47 | 47 | the repository. |
| 48 | 48 | </p> |
| 49 | 49 | <p> |
| 50 | 50 | Both commands have additional command-line options that can be used to refine |
| @@ -65,11 +65,11 @@ | ||
| 65 | 65 | </blockquote> |
| 66 | 66 | In this example, you are telling "inetd" that when an incoming connection |
| 67 | 67 | appears on port "12345", that it should launch the binary "/usr/bin/fossil" |
| 68 | 68 | program with the arguments shown. |
| 69 | 69 | Obviously you will |
| 70 | -need to modify the pathnames parts as appropriate for your particular setup. | |
| 70 | +need to modify the pathnames for your particular setup. | |
| 71 | 71 | The final argument is either the name of the fossil repository to be served, |
| 72 | 72 | or a directory containing multiple repositories. |
| 73 | 73 | </p> |
| 74 | 74 | <p> |
| 75 | 75 | If you system is running xinetd, then the configuration is likely to be |
| @@ -132,12 +132,12 @@ | ||
| 132 | 132 | </pre></blockquote> |
| 133 | 133 | </p> |
| 134 | 134 | <p> |
| 135 | 135 | As always, adjust your paths appropriately. |
| 136 | 136 | It may be necessary to set permissions properly, or to modify an ".htaccess" |
| 137 | -file or other server-specific things like that. Consult the documentation | |
| 138 | -for your particular server. | |
| 137 | +file or make other server-specific changes. Consult the documentation | |
| 138 | +for your particular web server. | |
| 139 | 139 | </p> |
| 140 | 140 | <p> |
| 141 | 141 | Once the script is set up correctly, and assuming your server is also set |
| 142 | 142 | correctly, you should be able to access your repository with a URL like: |
| 143 | 143 | <b>http://mydomain.org/cgi-bin/repo</b> (assuming the "repo" script is |
| @@ -186,11 +186,11 @@ | ||
| 186 | 186 | So it is necessary to provide the SCRIPT_NAME parameter in the configuration. |
| 187 | 187 | Failure to do this will cause Fossil to return an error. |
| 188 | 188 | </p> |
| 189 | 189 | <p> |
| 190 | 190 | All of the features of the stand-alone server mode described above, |
| 191 | -such as the ability to server a directory full of Fossil repositories | |
| 191 | +such as the ability to serve a directory full of Fossil repositories | |
| 192 | 192 | rather than just a single repository, work the same way in SCGI mode. |
| 193 | 193 | </p> |
| 194 | 194 | </blockquote> |
| 195 | 195 | |
| 196 | 196 | <h2>Securing a repository with SSL</h2><blockquote> |
| @@ -214,36 +214,6 @@ | ||
| 214 | 214 | <p> |
| 215 | 215 | For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>. |
| 216 | 216 | </p> |
| 217 | 217 | </blockquote> |
| 218 | 218 | |
| 219 | -<h2>Various security concerns with hosted repositories</h2><blockquote> | |
| 220 | -<p> | |
| 221 | -There are two main concerns relating to usage of Fossil for sharing | |
| 222 | -sensitive information (source or any other data): | |
| 223 | -<ul> | |
| 224 | -<li>Interception of the Fossil synchronization stream, thereby capturing | |
| 225 | -data, and | |
| 226 | -<li>Direct access to the Fossil repository on the server | |
| 227 | -</ul> | |
| 228 | -</p> | |
| 229 | -<p> | |
| 230 | -Regarding the first, it is adequate to secure the server using SSL, and | |
| 231 | -disallowing any non-SSL access. The data stream will be encrypted by | |
| 232 | -the HTTPS protocol, rendering the data reasonably secure. The truly | |
| 233 | -paranoid may wish to deploy <i>ssh</i> encrypted tunnels, but that is | |
| 234 | -quite a bit more difficult and cumbersome to set up (particularly for | |
| 235 | -a larger number of users). | |
| 236 | -</p> | |
| 237 | -<p> | |
| 238 | -As far as direct access to the repository, the same steps must be taken | |
| 239 | -as for any other internet-facing data-store. Access passwords to any | |
| 240 | -disk-accessing accounts should be strong (and preferably changed from | |
| 241 | -time to time). However, the data in the repository itself are <i>not</i> | |
| 242 | -encrypted (unless you save encrypted data yourself), and so the system | |
| 243 | -administrators of your server will be able to access your data (as with | |
| 244 | -any hosting service setup). The only workaround in this case is to | |
| 245 | -host the server yourself, in which case you will need to allocate | |
| 246 | -resources to deal with administration issues. | |
| 247 | -</p> | |
| 248 | - | |
| 249 | 219 | </blockquote> |
| 250 | 220 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -40,11 +40,11 @@ | |
| 40 | to the URL mentioned above, and "ui" command binds to |
| 41 | the loopback IP address (127.0.0.1) only so that the "ui" command cannot be |
| 42 | used to serve content to a different machine. |
| 43 | </p> |
| 44 | <p> |
| 45 | If one of the commands above is run from within an option checkout, |
| 46 | then the <i>REPOSITORY</i> argument can be omitted and the checkout is used as |
| 47 | the repository. |
| 48 | </p> |
| 49 | <p> |
| 50 | Both commands have additional command-line options that can be used to refine |
| @@ -65,11 +65,11 @@ | |
| 65 | </blockquote> |
| 66 | In this example, you are telling "inetd" that when an incoming connection |
| 67 | appears on port "12345", that it should launch the binary "/usr/bin/fossil" |
| 68 | program with the arguments shown. |
| 69 | Obviously you will |
| 70 | need to modify the pathnames parts as appropriate for your particular setup. |
| 71 | The final argument is either the name of the fossil repository to be served, |
| 72 | or a directory containing multiple repositories. |
| 73 | </p> |
| 74 | <p> |
| 75 | If you system is running xinetd, then the configuration is likely to be |
| @@ -132,12 +132,12 @@ | |
| 132 | </pre></blockquote> |
| 133 | </p> |
| 134 | <p> |
| 135 | As always, adjust your paths appropriately. |
| 136 | It may be necessary to set permissions properly, or to modify an ".htaccess" |
| 137 | file or other server-specific things like that. Consult the documentation |
| 138 | for your particular server. |
| 139 | </p> |
| 140 | <p> |
| 141 | Once the script is set up correctly, and assuming your server is also set |
| 142 | correctly, you should be able to access your repository with a URL like: |
| 143 | <b>http://mydomain.org/cgi-bin/repo</b> (assuming the "repo" script is |
| @@ -186,11 +186,11 @@ | |
| 186 | So it is necessary to provide the SCRIPT_NAME parameter in the configuration. |
| 187 | Failure to do this will cause Fossil to return an error. |
| 188 | </p> |
| 189 | <p> |
| 190 | All of the features of the stand-alone server mode described above, |
| 191 | such as the ability to server a directory full of Fossil repositories |
| 192 | rather than just a single repository, work the same way in SCGI mode. |
| 193 | </p> |
| 194 | </blockquote> |
| 195 | |
| 196 | <h2>Securing a repository with SSL</h2><blockquote> |
| @@ -214,36 +214,6 @@ | |
| 214 | <p> |
| 215 | For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>. |
| 216 | </p> |
| 217 | </blockquote> |
| 218 | |
| 219 | <h2>Various security concerns with hosted repositories</h2><blockquote> |
| 220 | <p> |
| 221 | There are two main concerns relating to usage of Fossil for sharing |
| 222 | sensitive information (source or any other data): |
| 223 | <ul> |
| 224 | <li>Interception of the Fossil synchronization stream, thereby capturing |
| 225 | data, and |
| 226 | <li>Direct access to the Fossil repository on the server |
| 227 | </ul> |
| 228 | </p> |
| 229 | <p> |
| 230 | Regarding the first, it is adequate to secure the server using SSL, and |
| 231 | disallowing any non-SSL access. The data stream will be encrypted by |
| 232 | the HTTPS protocol, rendering the data reasonably secure. The truly |
| 233 | paranoid may wish to deploy <i>ssh</i> encrypted tunnels, but that is |
| 234 | quite a bit more difficult and cumbersome to set up (particularly for |
| 235 | a larger number of users). |
| 236 | </p> |
| 237 | <p> |
| 238 | As far as direct access to the repository, the same steps must be taken |
| 239 | as for any other internet-facing data-store. Access passwords to any |
| 240 | disk-accessing accounts should be strong (and preferably changed from |
| 241 | time to time). However, the data in the repository itself are <i>not</i> |
| 242 | encrypted (unless you save encrypted data yourself), and so the system |
| 243 | administrators of your server will be able to access your data (as with |
| 244 | any hosting service setup). The only workaround in this case is to |
| 245 | host the server yourself, in which case you will need to allocate |
| 246 | resources to deal with administration issues. |
| 247 | </p> |
| 248 | |
| 249 | </blockquote> |
| 250 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -40,11 +40,11 @@ | |
| 40 | to the URL mentioned above, and "ui" command binds to |
| 41 | the loopback IP address (127.0.0.1) only so that the "ui" command cannot be |
| 42 | used to serve content to a different machine. |
| 43 | </p> |
| 44 | <p> |
| 45 | If one of the commands above is run from within an open checkout, |
| 46 | then the <i>REPOSITORY</i> argument can be omitted and the checkout is used as |
| 47 | the repository. |
| 48 | </p> |
| 49 | <p> |
| 50 | Both commands have additional command-line options that can be used to refine |
| @@ -65,11 +65,11 @@ | |
| 65 | </blockquote> |
| 66 | In this example, you are telling "inetd" that when an incoming connection |
| 67 | appears on port "12345", that it should launch the binary "/usr/bin/fossil" |
| 68 | program with the arguments shown. |
| 69 | Obviously you will |
| 70 | need to modify the pathnames for your particular setup. |
| 71 | The final argument is either the name of the fossil repository to be served, |
| 72 | or a directory containing multiple repositories. |
| 73 | </p> |
| 74 | <p> |
| 75 | If you system is running xinetd, then the configuration is likely to be |
| @@ -132,12 +132,12 @@ | |
| 132 | </pre></blockquote> |
| 133 | </p> |
| 134 | <p> |
| 135 | As always, adjust your paths appropriately. |
| 136 | It may be necessary to set permissions properly, or to modify an ".htaccess" |
| 137 | file or make other server-specific changes. Consult the documentation |
| 138 | for your particular web server. |
| 139 | </p> |
| 140 | <p> |
| 141 | Once the script is set up correctly, and assuming your server is also set |
| 142 | correctly, you should be able to access your repository with a URL like: |
| 143 | <b>http://mydomain.org/cgi-bin/repo</b> (assuming the "repo" script is |
| @@ -186,11 +186,11 @@ | |
| 186 | So it is necessary to provide the SCRIPT_NAME parameter in the configuration. |
| 187 | Failure to do this will cause Fossil to return an error. |
| 188 | </p> |
| 189 | <p> |
| 190 | All of the features of the stand-alone server mode described above, |
| 191 | such as the ability to serve a directory full of Fossil repositories |
| 192 | rather than just a single repository, work the same way in SCGI mode. |
| 193 | </p> |
| 194 | </blockquote> |
| 195 | |
| 196 | <h2>Securing a repository with SSL</h2><blockquote> |
| @@ -214,36 +214,6 @@ | |
| 214 | <p> |
| 215 | For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>. |
| 216 | </p> |
| 217 | </blockquote> |
| 218 | |
| 219 | </blockquote> |
| 220 |