Fossil SCM

I'm noticing that there doesn't seem to be a configuration parameter or any reasonable way to enforce all communications to use SSL-secured HTTP in the Web interface.

My current hosting setup is as follows:

# /etc/xinetd.d/fossil-some-site 
service fossil-some-site
{
    socket_type = stream
    type = UNLISTED
    wait = no
    disable = no
    user = root
    server = /opt/fossil/bin/fossil
    server_args = http /opt/fossil/repositories/some.site/fossil --notfound http://fossil.some.site/cgi-bin/fossil-list-repositories.cgi
    bind = fossil-some-site.fossil01.internal
    port = 8060
}

# /etc/httpd/vhosts.d/includes/fossil.some.site.conf 
# Mostly standard Red Hat virtual host boilerplate elided.

ProxyPass /cgi-bin !
ProxyPass / http://fossil.some.site/
ProxyPassReverse /cgi-bin !
ProxyPassReverse / http://fossil.some.site/

# /etc/hosts
127.0.0.1 localhost.localdomain localhost fossil01.internal fossil01
127.0.0.101 fossil-some-site.fossil01.internal fossil.some.site
...

I haven't explored using the CGI method of deployment yet, nor have I explored the possibility of contributing patches to make this functionality a reality. I also haven't explored whether or not this functionality already exists in a newer release, seeing as I am running a relatively ancient version of Fossil:

fossil01% /opt/fossil/bin/fossil version
This is fossil version [d0753799e4] 2010-11-01 14:23:35 UTC

My current workaround is just to interact with the software through the shell on the remote end (to set configuration parameters, manage users, etc.) and through the usual fossil update, fossil sync, et al. commands from my working copy, wherever it might be at the time.

I would like to be able to use the Web interface running remotely however. :)

drh added on 2011-01-18 15:16:11 UTC: See [http://www.stunnel.org/] for a better solution.

service https
{
  port = 443
  socket_type = stream
  wait = no
  user = root
  server = /usr/bin/stunnel
  server_args = -l /opt/fossil -- fossil http /var/repo/some-site.fossil
}

dmitry added on 2011-01-18 16:00:06 UTC: Will this work (untested)?

# /etc/httpd/vhosts.d/includes/fossil.some.site.conf 
# Mostly standard Red Hat virtual host boilerplate elided.


  ServerName  fossil.some.site
  Redirect / https://fossil.some.site



  ServerName  fossil.some.site
  # ... your proxy settings ...

anonymous added on 2011-01-18 18:17:33 UTC: I'm thinking that I need to provide a bit more informative context. I'm inferring from your response that your assumption is that I don't have the SSL-enabled vhost set up. Alas, I do:

# /etc/httpd/vhosts.d/fossil.some.site-ssl.conf 
<VirtualHost 10.10.161.25:443>
    Include vhosts.d/includes/fossil.some.site.conf

    SSLEngine on
    SSLCertificateFile /var/www/domains/some.site/fossil/ssl/fossil.some.site.crt
    SSLCertificateKeyFile /var/www/domains/some.site/fossil/ssl/fossil.some.site.2048.key
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
</VirtualHost>

# /etc/httpd/vhosts.d/fossil.some.site.conf 
<VirtualHost 10.10.161.25:80>
    Include vhosts.d/includes/fossil.some.site.conf

        RewriteEngine On
        RewriteCond %{HTTPS} off [NC]
        RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [R=permanent,L]
</VirtualHost>

The relevant resulting HTML of, e.g., https://fossil.some.site/Fossil-Repository/wikinew is as follows:

<form method="post" action="http://fossil.some.site/Fossil-Repository/wikinew">
<p>Name of new wiki page:
<input style="width: 35;" type="text" name="name" value="" />
<input type="submit" value="Create" />
</p></form>

The issue is that, while Fossil traffic using the fossil tool is carried over SSL-secured HTTP just fine, the Web interface will revert back to insecure HTTP for communications in situations like these.

dmitry added on 2011-01-18 18:29:28 UTC: I see, thanks for explanation (I forgot about the actual data sent to webserver, and thought redirects would handle this).

I think the fix for this would be to change "http://" everywhere in fossil's code which generates webpages to just "//", so that it prints them like this: