RevCGI Hosts?

Andre Garzia andre at
Tue Feb 19 22:09:22 EST 2008

Where is he now? I never had a chance to talk to him.


On 2/19/08, J. Landman Gay <jacque at> 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         |     jacque at
> HyperActive Software           |
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

-- All We Do Is Code.

More information about the Use-livecode mailing list