Discussion:
Chiselapp status
(too old to reply)
Andy Goth
2018-07-13 19:37:07 UTC
Permalink
Whom should I be talking to regarding Chiselapp questions? I want to
know if there's a reason why it uses Fossil version 2.1 [83e3445f67] and
if there are any plans to upgrade.

I've not gotten any email replies from Roy Keene in a long time, neither
regarding Tcl nor Chiselapp, though I know he's out there because of
recent commits to his kitcreator project. Perhaps I just don't have the
right address.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
Roy Keene
2018-07-13 20:13:18 UTC
Permalink
It's still me -- though I don't check email that often, and when I do I
don't read all of it, normally just the subject and sometimes the From.

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.

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

Thanks,
Roy Keene

P.S., I'm usually on the Tcl IRC or Slack ( https://slack.tcl-lang.org ).
Whom should I be talking to regarding Chiselapp questions? I want to know if
there's a reason why it uses Fossil version 2.1 [83e3445f67] and if there are
any plans to upgrade.
I've not gotten any email replies from Roy Keene in a long time, neither
regarding Tcl nor Chiselapp, though I know he's out there because of recent
commits to his kitcreator project. Perhaps I just don't have the right
address.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2018-07-13 20:59:22 UTC
Permalink
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 interact?

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:

https://unix.stackexchange.com/questions/127001/linux-lxc-vs-freebsd-jail

https://www.blackhat.com/docs/eu-15/materials/eu-15-Bettini-Vulnerability-Exploitation-In-Docker-Container-Environments-wp.pdf

https://www.reddit.com/r/IAmA/comments/31ny87/i_am_the_cto_of_joyent_the_father_of_dtrace_and/cq414ac

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 numbers.
Loading...