On 3 August 2012 16:03, Stephan Beal <[email protected]> wrote: > On Fri, Aug 3, 2012 at 3:49 PM, Michal Suchanek <[email protected]> wrote: >> >> And how do you prevent malicious code import through synchronization? > > > The same way Windows does, of course: "This app comes from god-only-knows > where. Do you want to run it?" > > ;) > > i have absolutely no idea, to be honest.
Well, you don't because your system has no security. No system in wide use today has. > >> >> This is the exact same thing. Either you don't import or don't use >> what you import or you are vulnerable to what you import. > > > The difference with custom commands, compared to what is currently syncable, > is that they will have a lot more power via access to stuff which was not > accessible before. e.g. a query API has been added to the scripting language > (th1). One very interesting (under consideration) feature of custom > commands/pages is that we could _potentially_ offer an option to direct > built-in commands to a custom command. If such things are synced, then i > might get your version of "fossil status" instead of mine, and that would > upset me. The custom commands API currently offers nothing which will allow > one to change a repo's state and there are NO plans to add such APIs, for > repo integrity reasons. Even so, with greater power comes bigger cans of > worms, so any synchronization must be carefully considered. I don't think that doing this is desirable. fossil status should be fossil status. You might want to write a separate script to replace it. It might be useful to be able to make fossil mystatus, too. The web interface is optional and it is fine to be able to change it with synchronization. Of course, if you run fossil serve and browse to the web interface which is synchronized from upstream you are open to browser attacks. But the same applies if you browse HTML documentation included in the project (or PDF documentation with overly clever PDF reader), or run projects build or other scripts, or run the binaries. > > Initial templates/commands support _might_ live in a new table of its own > (this is still undecided) which will initially not be syncable but would > eventually be made so, _probably_ via an extension of the "config" command > (or something equivalent). They might live in the artifacts table (where > they could be versioned and synced as normal artifacts), and whether or not > to version custom pages/commands is a decision which has not yet been made > (as always: opinions on the matter are welcomed). It might be interesting, > and wouldn't be much work, to provide several methods for storing custom > commands: config table, artifacts, and/or local files. e.g. for prototyping > this support i use local files, and once i'm (eventually) satisfied with the > overall model i'll figure out (hopefully with the help of the community) > where best to store such things. Versioning them is probably a good idea. Still if you are editing and testing the pages in the browser it might be good idea to make whatever you save a 'checkout' which is only synced when you 'commit' it. Otherwise you are going to make tons of small meaningless commits as you edit small details of templates and stylesheets. Thanks Michal _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
