On Jul 13, 2018, at 2:13 PM, Roy Keene <fos...@rkeene.org> wrote:
> Upgrading from Fossil 2.1 to something more recent hasn't been a priority;  I 
> have to go through the versions and verify no new features will cause 
> problems when hosting untrusted repositories, and I haven't done that.

I guess you’re worried about CSRF, XSS and such?

There was an XSS fix in 2.3, and there’s one still pending for the current 
release.  I didn’t pay attention to who noticed these problems and wanted these 
fixes, but if you’d asked me yesterday, I’d have guessed Chiselapp!

> If you would like to volunteer to do that then it'll go faster !  :-D

Would it be easier to switch to a technology like BSD jails or Illumos zones 
that let you run a separate Fossil instance for each customer, so that you 
don’t have to worry about how multiple customers’ Fossil instances will 

With Fossil’s option of a single statically-linked executable, you might end up 
with only a handful of files in each container, so that the attack surface is 
little more than Fossil itself, and if exploited, all you get access to is the 
repository data within that single container.

cgroups based containers on Linux (e.g. Docker, though not limited to it) are 
reportedly not as strong as BSD jails or Illumos zones:




Yet, they may be strong enough for this purpose, given its tight scoping.

chroot() might even be strong enough given the tight scoping.  None of the ways 
I’m aware of to escape a chroot() apply to a minimal Fossil-in-a-box 
configuration.  Most of these methods require root access inside the chroot, 
and there isn’t cause for that, not even for low-numbered port binding, since 
your HTTPS front end could map external URLs to high-numbered internal port 
fossil-users mailing list

Reply via email to