Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Wed, Feb 15, 2012 at 11:15 PM, Nolan Darilek no...@thewordnerd.infowrote: So is it currently possible to use TH1 to generate dynamic webpages? Could I use it to, say, select the last 5 events and display them on the main page? Or is that still out of reach? Just curious, since it seems like there are lots of scripting possibilities coming down the pipeline. Thanks! I was once open to this kind of thing. But since the security risks have been pointed out to me, I'm now very reluctant to do anything like this. On 02/14/2012 06:58 AM, Richard Hipp wrote: On Tue, Feb 14, 2012 at 7:53 AM, Richard Hipp d...@sqlite.org wrote: On Mon, Feb 13, 2012 at 9:26 PM, Leo Razoumov slonik...@gmail.comwrote: Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. The only actions TH1 can take are to output text or HTML into designated areas of a webpage. TH1 cannot change the repository, cannot write to the disk, cannot open network connections, cannot read content from external sources, cannot consume large amounts of memory, cannot loop, and cannot call external programs or software. TH1 is not a serious threat for malware. TCL can do more mischief, but it is only enabled if you compile with FOSSIL_ENABLE_TCL, which is off by default, and if you either set the tcl property on your repository or have the TH1_ENABLE_TCL environment variable set. Moving forward, I think I'll make further security enhancements along the following lines: (1) Disable the TH1_ENABLE_TCL environment variable. TCL script capability is only available if you enable it using the tcl property of the repository. (2) Default the tcl property to off on a clone, even if it is on in the parent repo. (3) Provide extra setup screens that make it easier to audit scripts for malware prior to enabling the tcl property. At the place where the tcl property is enabled, include text warning users of the potential dangers and provide buttons or links to places where the TCL script can be audited for security. (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. (5) If any script changes as a result of fossil config pull then the tcl property is automatically moved to off and the operator is notified. The tcl property must be turned back on by a separate manual step, that includes a warning to make sure the modified scripts are secure. -- D. Richard Hipp d...@sqlite.org -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing listfossil-users@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On 02/16/2012 06:55 AM, Richard Hipp wrote: On Wed, Feb 15, 2012 at 11:15 PM, Nolan Darilek no...@thewordnerd.info mailto:no...@thewordnerd.info wrote: So is it currently possible to use TH1 to generate dynamic webpages? Could I use it to, say, select the last 5 events and display them on the main page? Or is that still out of reach? Just curious, since it seems like there are lots of scripting possibilities coming down the pipeline. Thanks! I was once open to this kind of thing. But since the security risks have been pointed out to me, I'm now very reluctant to do anything like this. I thought the point of TH1 was that it prevented this type of thing, that's why it's used in reporting. If TH1 isn't a secure, minimal TCL that can generate reports and, presumably, might be expanded a bit to pull and display information on artifacts, then what is it? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
Cool, I'd like to at least have the discussion about that, though. What I'd like to see, if possible, is read-only access to the repository--access to the SELECT statement, for instance, and a way to iterate over the results and output them into the pages. To anyone afraid that I'll be calling for full-blown CMS features next, I'll note that hooks and the ability to display arbitrary repository content are the only features I've missed after nearly two years of Fossil use. I'm using it quite happily for the http://spielproject.info pages, but I'd love to display the last 5-10 events on the front page to liven it up a bit. Events are how I announce releases. I could also see displaying timeline entries and such to show the X most recent commits on certain pages, etc. Yeah, I know I can do this with Javascript, but that doesn't make the content searchable. Thanks. On 02/16/2012 08:00 AM, Richard Hipp wrote: On Thu, Feb 16, 2012 at 8:49 AM, Nolan Darilek no...@thewordnerd.info mailto:no...@thewordnerd.info wrote: On 02/16/2012 06:55 AM, Richard Hipp wrote: On Wed, Feb 15, 2012 at 11:15 PM, Nolan Darilek no...@thewordnerd.info mailto:no...@thewordnerd.info wrote: So is it currently possible to use TH1 to generate dynamic webpages? Could I use it to, say, select the last 5 events and display them on the main page? Or is that still out of reach? Just curious, since it seems like there are lots of scripting possibilities coming down the pipeline. Thanks! I was once open to this kind of thing. But since the security risks have been pointed out to me, I'm now very reluctant to do anything like this. I thought the point of TH1 was that it prevented this type of thing, that's why it's used in reporting. If TH1 isn't a secure, minimal TCL that can generate reports and, presumably, might be expanded a bit to pull and display information on artifacts, then what is it? TH1 is secure by virtual of being minimalist. It really doesn't do much beyond simple variable substitution and if-then-else. The point is, I want to keep it that way so that it does not evolve into a security threat. We want to keep the attack surface as small as possible. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org mailto:fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org mailto:d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Thu, Feb 16, 2012 at 09:00, Richard Hipp d...@sqlite.org wrote: I was once open to this kind of thing. But since the security risks have been pointed out to me, I'm now very reluctant to do anything like this. TH1 is secure by virtual of being minimalist. It really doesn't do much beyond simple variable substitution and if-then-else. The point is, I want to keep it that way so that it does not evolve into a security threat. We want to keep the attack surface as small as possible. I appreciate the security above all attitude. But if at some point in the future scripting will be back on discussion table I would like to introduce embedded language Lua [1], [2]. It has some really unique features that are greatly appreciated in embedded scripting world. Here just few of them: (1) Implemented in ANSI C-89 with no external dependencies, highly portable. Small code base (15 KLOC) (2) Designed as embedded language from get go. Great configurable sand-boxing (3) Very easy to interface to existing C-code. Lua can call C-functions and can be called from C-functions. (4) Very fast (faster than TCL, python, ruby, perl). For real CPU addicts there is Just-In-Time compiler LuaJIT which delivers Java-6 like performance on average and sometimes comes close to C. (5) Simple syntax, powerful semantics. [1] http://www.lua.org [2] http://en.wikipedia.org/wiki/Lua_%28programming_language%29 --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On 17/02/2012, at 2:15 AM, Nolan Darilek wrote: Cool, I'd like to at least have the discussion about that, though. What I'd like to see, if possible, is read-only access to the repository--access to the SELECT statement, for instance, and a way to iterate over the results and output them into the pages. To anyone afraid that I'll be calling for full-blown CMS features next, I'll note that hooks and the ability to display arbitrary repository content are the only features I've missed after nearly two years of Fossil use. I'm using it quite happily for the http://spielproject.info pages, but I'd love to display the last 5-10 events on the front page to liven it up a bit. Events are how I announce releases. I could also see displaying timeline entries and such to show the X most recent commits on certain pages, etc. Yeah, I know I can do this with Javascript, but that doesn't make the content searchable. Thanks. FWIW, you could turn a Jim Tcl interpreter into a safe interpreter by removing a handful of commands from the interpreter, such as: readdir, open, exec, source, cd, file To be most useful, read-only access to the fossil db (with some restrictions?) would also be required. Of course, Jim Tcl were used for hook scripts, this interpreter would need to be non-safe to be useful. Cheers, Steve On 02/16/2012 08:00 AM, Richard Hipp wrote: On Thu, Feb 16, 2012 at 8:49 AM, Nolan Darilek no...@thewordnerd.info wrote: On 02/16/2012 06:55 AM, Richard Hipp wrote: On Wed, Feb 15, 2012 at 11:15 PM, Nolan Darilek no...@thewordnerd.info wrote: So is it currently possible to use TH1 to generate dynamic webpages? Could I use it to, say, select the last 5 events and display them on the main page? Or is that still out of reach? Just curious, since it seems like there are lots of scripting possibilities coming down the pipeline. Thanks! I was once open to this kind of thing. But since the security risks have been pointed out to me, I'm now very reluctant to do anything like this. I thought the point of TH1 was that it prevented this type of thing, that's why it's used in reporting. If TH1 isn't a secure, minimal TCL that can generate reports and, presumably, might be expanded a bit to pull and display information on artifacts, then what is it? TH1 is secure by virtual of being minimalist. It really doesn't do much beyond simple variable substitution and if-then-else. The point is, I want to keep it that way so that it does not evolve into a security threat. We want to keep the attack surface as small as possible. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
So is it currently possible to use TH1 to generate dynamic webpages? Could I use it to, say, select the last 5 events and display them on the main page? Or is that still out of reach? Just curious, since it seems like there are lots of scripting possibilities coming down the pipeline. Thanks! On 02/14/2012 06:58 AM, Richard Hipp wrote: On Tue, Feb 14, 2012 at 7:53 AM, Richard Hipp d...@sqlite.org mailto:d...@sqlite.org wrote: On Mon, Feb 13, 2012 at 9:26 PM, Leo Razoumov slonik...@gmail.com mailto:slonik...@gmail.com wrote: Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. The only actions TH1 can take are to output text or HTML into designated areas of a webpage. TH1 cannot change the repository, cannot write to the disk, cannot open network connections, cannot read content from external sources, cannot consume large amounts of memory, cannot loop, and cannot call external programs or software. TH1 is not a serious threat for malware. TCL can do more mischief, but it is only enabled if you compile with FOSSIL_ENABLE_TCL, which is off by default, and if you either set the tcl property on your repository or have the TH1_ENABLE_TCL environment variable set. Moving forward, I think I'll make further security enhancements along the following lines: (1) Disable the TH1_ENABLE_TCL environment variable. TCL script capability is only available if you enable it using the tcl property of the repository. (2) Default the tcl property to off on a clone, even if it is on in the parent repo. (3) Provide extra setup screens that make it easier to audit scripts for malware prior to enabling the tcl property. At the place where the tcl property is enabled, include text warning users of the potential dangers and provide buttons or links to places where the TCL script can be audited for security. (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. (5) If any script changes as a result of fossil config pull then the tcl property is automatically moved to off and the operator is notified. The tcl property must be turned back on by a separate manual step, that includes a warning to make sure the modified scripts are secure. -- D. Richard Hipp d...@sqlite.org mailto:d...@sqlite.org -- D. Richard Hipp d...@sqlite.org mailto:d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 9:26 PM, Leo Razoumov slonik...@gmail.com wrote: Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. The only actions TH1 can take are to output text or HTML into designated areas of a webpage. TH1 cannot change the repository, cannot write to the disk, cannot open network connections, cannot read content from external sources, cannot consume large amounts of memory, cannot loop, and cannot call external programs or software. TH1 is not a serious threat for malware. TCL can do more mischief, but it is only enabled if you compile with FOSSIL_ENABLE_TCL, which is off by default, and if you either set the tcl property on your repository or have the TH1_ENABLE_TCL environment variable set. Moving forward, I think I'll make further security enhancements along the following lines: (1) Disable the TH1_ENABLE_TCL environment variable. TCL script capability is only available if you enable it using the tcl property of the repository. (2) Default the tcl property to off on a clone, even if it is on in the parent repo. (3) Provide extra setup screens that make it easier to audit scripts for malware prior to enabling the tcl property. At the place where the tcl property is enabled, include text warning users of the potential dangers and provide buttons or links to places where the TCL script can be audited for security. (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Tue, Feb 14, 2012 at 7:53 AM, Richard Hipp d...@sqlite.org wrote: On Mon, Feb 13, 2012 at 9:26 PM, Leo Razoumov slonik...@gmail.com wrote: Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. The only actions TH1 can take are to output text or HTML into designated areas of a webpage. TH1 cannot change the repository, cannot write to the disk, cannot open network connections, cannot read content from external sources, cannot consume large amounts of memory, cannot loop, and cannot call external programs or software. TH1 is not a serious threat for malware. TCL can do more mischief, but it is only enabled if you compile with FOSSIL_ENABLE_TCL, which is off by default, and if you either set the tcl property on your repository or have the TH1_ENABLE_TCL environment variable set. Moving forward, I think I'll make further security enhancements along the following lines: (1) Disable the TH1_ENABLE_TCL environment variable. TCL script capability is only available if you enable it using the tcl property of the repository. (2) Default the tcl property to off on a clone, even if it is on in the parent repo. (3) Provide extra setup screens that make it easier to audit scripts for malware prior to enabling the tcl property. At the place where the tcl property is enabled, include text warning users of the potential dangers and provide buttons or links to places where the TCL script can be audited for security. (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. (5) If any script changes as a result of fossil config pull then the tcl property is automatically moved to off and the operator is notified. The tcl property must be turned back on by a separate manual step, that includes a warning to make sure the modified scripts are secure. -- D. Richard Hipp d...@sqlite.org -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Tue, Feb 14, 2012 at 07:53, Richard Hipp d...@sqlite.org wrote: (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. IMHO fossil clone should *NOT* transfer scripts. Cloning is such a common operation that I do it all the time on a whim without much thoughts. Can easily do things that I will regret later. On the other hand, somethings like fossil configuration pull scripts ... requires just enough extra typing to make it a conscious effort. Also, it would be great to have a -n or --nochange dry-run option to tell a user whether there are any scripts to pull or push. Just my 2c --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Tue, Feb 14, 2012 at 01:01:39PM -0500, Leo Razoumov wrote: On Tue, Feb 14, 2012 at 07:53, Richard Hipp d...@sqlite.org wrote: (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. IMHO fossil clone should *NOT* transfer scripts. Cloning is such a common operation that I do it all the time on a whim without much thoughts. Can easily do things that I will regret later. In the case where we want versioned hook script. Mean, calling script that is inside the repository. A clone/pull will update it, but the setting that make it enable or not would be in the configuration part. And That's why one of the Richard point was that if a script get modified during a pull, the hook would be disable systematically and the user would have to audit the script and decide if he want to enable it back or not. On the other hand, somethings like fossil configuration pull scripts ... requires just enough extra typing to make it a conscious effort. Also, it would be great to have a -n or --nochange dry-run option to tell a user whether there are any scripts to pull or push. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
I think it may be very useful if it was possible to call tcl scripts stored in the repo db (revision controlled files or wiki pages?) at pre/post commit and other interesting times. I know hooks were previously not accepted since making things consistent between Windows and Linux was difficult. But that concern should be addressed if the hooks call tcl or th1 scripts instead of directly sending commands to the OS. It looks like jimtcl supplies os.fork, os.wait etc. but I didn't see a posix system, can jimtcl run commands on Unix? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On 14/02/2012, at 4:22 AM, Matt Welland wrote: I think it may be very useful if it was possible to call tcl scripts stored in the repo db (revision controlled files or wiki pages?) at pre/post commit and other interesting times. I know hooks were previously not accepted since making things consistent between Windows and Linux was difficult. But that concern should be addressed if the hooks call tcl or th1 scripts instead of directly sending commands to the OS. It looks like jimtcl supplies os.fork, os.wait etc. but I didn't see a posix system, can jimtcl run commands on Unix? Yes, indeed! You want the 'exec' command - http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_exec You can try this out with the 'jimtcl' branch of fossil. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 1:43 PM, Steve Bennett ste...@workware.net.auwrote: On 14/02/2012, at 4:22 AM, Matt Welland wrote: I think it may be very useful if it was possible to call tcl scripts stored in the repo db (revision controlled files or wiki pages?) at pre/post commit and other interesting times. I know hooks were previously not accepted since making things consistent between Windows and Linux was difficult. But that concern should be addressed if the hooks call tcl or th1 scripts instead of directly sending commands to the OS. It looks like jimtcl supplies os.fork, os.wait etc. but I didn't see a posix system, can jimtcl run commands on Unix? Yes, indeed! You want the 'exec' command - http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_exec You can try this out with the 'jimtcl' branch of fossil. Hi Steve, This sounds cool, so is the mechanism to call a jimtcl routine implemented on various actions and if so then how do I, for example, call a tcl script when sync is completed? Thanks, Matt -=- Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On 14/02/2012, at 7:38 AM, Matt Welland wrote: On Mon, Feb 13, 2012 at 1:43 PM, Steve Bennett ste...@workware.net.au wrote: On 14/02/2012, at 4:22 AM, Matt Welland wrote: I think it may be very useful if it was possible to call tcl scripts stored in the repo db (revision controlled files or wiki pages?) at pre/post commit and other interesting times. I know hooks were previously not accepted since making things consistent between Windows and Linux was difficult. But that concern should be addressed if the hooks call tcl or th1 scripts instead of directly sending commands to the OS. It looks like jimtcl supplies os.fork, os.wait etc. but I didn't see a posix system, can jimtcl run commands on Unix? Yes, indeed! You want the 'exec' command - http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_exec You can try this out with the 'jimtcl' branch of fossil. Hi Steve, This sounds cool, so is the mechanism to call a jimtcl routine implemented on various actions and if so then how do I, for example, call a tcl script when sync is completed? Joe Mistachkin has recently added support for calling TH1 scripts on certain actions. See http://www.fossil-scm.org/index.html/info/0b61e3c019 In the jimtcl branch, TH1 is replaced with Jim Tcl, so any of these scripts has the full power of Jim Tcl, including exec. There is some ongoing work to be done to identify other points where a script could/should be called, what information is available to the script, and what the script can do. One thing I would like to see is a Tcl interface into fossil so that scripts can do queries against fossil without resorting to direct sql. Cheers, Steve Thanks, Matt -=- Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
The current Fossil trunk is capable of using TH1 and Tcl in tandem.
First, during configure, enable Tcl support using:
./configure --with-tcl=/path/to/tcl
Then, make sure the tcl setting is enabled for the repository (or
globally).
fossil settings tcl 1
Finally, in the TH1 script, you can use:
tclEval {puts stdout [clock seconds]}
tclInvoke puts stdout via Tcl invoke
tclExpr 2+2
To obtain the full path and file name of the Fossil repository, the TH1
repository command may be used:
tclInvoke set repository_name [repository 1]
Also, Tcl can evaluate TH1 scripts as well:
tclInvoke th1Eval {set y two words}
tclInvoke th1Expr {2+2}
tclEval {set repository_name [th1Eval repository 1]}
When evaluating Tcl scripts from TH1, all Tcl commands and packages (e.g.
SQLite)
that would be available from tclsh are available in addition to the TH1
specific
commands th1Eval and th1Expr.
--
Joe Mistachkin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 1:49 PM, Steve Bennett ste...@workware.net.auwrote: Joe Mistachkin has recently added support for calling TH1 scripts on certain actions. See http://www.fossil-scm.org/index.html/info/0b61e3c019 In the jimtcl branch, TH1 is replaced with Jim Tcl, so any of these scripts has the full power of Jim Tcl, including exec. This sounds a whole lot like mobile code. I was left wondering: would it be enough to do a 'fossil clone something' to download a malware script onto my system? How is this capability secured? -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
Maybe make them a config area that must be explicitly pushed, pulled or synced along with skins, users, etc.? (Assuming that isn't how they're already implemented.) On 02/13/2012 05:37 PM, Steve Bennett wrote: On 14/02/2012, at 9:30 AM, Gé Weijers wrote: On Mon, Feb 13, 2012 at 1:49 PM, Steve Bennett ste...@workware.net.au mailto:ste...@workware.net.au wrote: Joe Mistachkin has recently added support for calling TH1 scripts on certain actions. See http://www.fossil-scm.org/index.html/info/0b61e3c019 In the jimtcl branch, TH1 is replaced with Jim Tcl, so any of these scripts has the full power of Jim Tcl, including exec. This sounds a whole lot like mobile code. I was left wondering: would it be enough to do a 'fossil clone something' to download a malware script onto my system? How is this capability secured? I'm sure Joe could tell you how it is implemented, but I don't see how it would make any sense to clone these scripts. Aren't some settings transferred with clone and some not? Surely these are in the not group. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au http://www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au mailto:ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 18:30, Gé Weijers g...@weijers.org wrote: On Mon, Feb 13, 2012 at 1:49 PM, Steve Bennett ste...@workware.net.au wrote: Joe Mistachkin has recently added support for calling TH1 scripts on certain actions. See http://www.fossil-scm.org/index.html/info/0b61e3c019 In the jimtcl branch, TH1 is replaced with Jim Tcl, so any of these scripts has the full power of Jim Tcl, including exec. This sounds a whole lot like mobile code. I was left wondering: would it be enough to do a 'fossil clone something' to download a malware script onto my system? How is this capability secured? Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
