On Sat, May 12, 2018 at 1:51 PM, Chris Drexler <ckolum...@ac-drexler.de>

> Thoughts? If someone could hint me at the right place within the
> fossil code I could also try to provide an implementation.

IMO: every clone would not have that feature, so it would seem (to me) to
be of limited use. The only benefit would be that you only have 1 file,
instead of 2, to copy to the remote server. (If you build your binary on
that server, even that benefit is lost.) If your server is upgraded in a
way which becomes incompatible with your fossil binary (incompatible SSL
upgrade or (possibly) libc upgrade), you're hosed: the repo is then locked
inside a binary file which other fossil binaries cannot read. (i've had
hoster-side OS upgrades break my CGI binaries before, though i don't think
i've seen it happen to my fossil binaries.)

Another point to consider: the binary itself would have to be writable by
the web server process, which opens up a potential security hole. In my
experience, Apache runs CGI scripts as the account holder (as opposed to
some generic 'www' user), and that account holder already has write access
to the binary. However, i make my CGI bins read-only, even to myself, "just
in case" (because one too many wordpress vulnerabilities have made me
paranoid in that regard).

It sounds to me like such a feature is tantamount to walking a minefield in
which any given mine could leave you unable to access the repository data.

Just my opinion, of course. It may very well work out fine for you.

----- stephan beal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
fossil-users mailing list

Reply via email to