Where is he now? I never had a chance to talk to him. :D andre
On 2/19/08, J. Landman Gay <[EMAIL PROTECTED]> wrote: > Dave Cragg wrote: > > > I may just be nervous by nature, but I never put the engine in the > > cgi-bin folder. By my understanding, the http server will try to execute > > anything in the cgi-bin folder that has execute permissions set. My > > worry is whether the server can be coerced into passing parameters when > > it tries to run the engine. (There was a security problem in the past > > with the Perl executable on Windows due to this.) While I'm fairly > > confident Rev is immune from this, why take the risk? > > I think we can relax as long as we don't script anything stupid. Here > are a couple of quotes from Scott Raney about it: > > > With MetaCard your primary (and probably exclusive) risk would be in > > executing commands or evaluating expressions that come from untrusted > > sources. Any use of the "do" and "send" commands or the "value" > > function should be very diligently evaluated to make sure that there > > is no possibility of this occuring. Of course, you also have to be > > careful about where you write files, but it's a relatively simple > > matter to check a path for validity (e.g., don't allow a leading > > "/", or the "..", ":", or "~" characters anywhere in a path). > > Which he follows with: > > > I certainly wouldn't rule out building or using MetaCard server > > software, even for protocols for which well-known (if buggy) open > > source software is widely available. While I don't see any big > > advantage to writing an FTP server in MetaCard, an HTTP server that > > executes CGI scripts is a different matter entirely and an area where > > a MetaCard server could be safer and feature-competitive with any of > > the alternatives. > > > <snip> > > > > I've got a soap box here too, and in *my* opinion, the ubiquity of > > buffer-overrun bugs in open source software rises to the level of > > criminal negligence. There is just no excuse for this kind of sloppy > > programming, yet not a week goes by that yet another example of this > > kind of thing isn't found in one of the commonly used open-source > > packages. I wouldn't blindly trust Microsoft software either, but at > > least the majority of the security holes in their products were put > > there deliberately to improve the usability of the products rather > > than as the result of poor security hygiene on the part of the > > developer. > > > > My advice is to not be afraid of this stuff. Sure, you have to be > > careful, but you can hardly do any worse a job than those hacks who > > are writing the software that runs the Internet ;-) > > I miss that guy. > > -- > Jacqueline Landman Gay | [EMAIL PROTECTED] > HyperActive Software | http://www.hyperactivesw.com > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > -- http://www.andregarzia.com All We Do Is Code. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
