On Sat, May 12, 2018 at 1:51 PM, Chris Drexler <ckolum...@ac-drexler.de> wrote:
> 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 http://wanderinghorse.net/home/stephan/ "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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
