You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 2000/02/22 01:04:58 UTC

htdocs/manual/search/manual-index.cgi

This doesn't properly encode its output.

Fortunately, it uses a freaky perl path that won't exist on the vast
majority of systems.  

I'm not sure we should be putting CGIs like this in the default doctree
anyway... sure, ExecCGI has to be enabled to make it work, but still...


Re: htdocs/manual/search/manual-index.cgi

Posted by James Sutherland <ja...@cam.ac.uk>.
On Mon, 21 Feb 2000, Marc Slemko wrote:

> I don't know that expand.pl belongs is manual/ either.  It isn't great
> that any random user can run this from the web if you enable execution of
> .pl files; sure, it doesn't let them do so much, but the general
> concept...

Well, according to the instructions on what does [not] go into release
tarballs, expand.pl is supposed to be deleted before release anyway
(http://dev.apache.org/how-to-release.html step 11 part 3). It should only
ever exist in the CVS tree itself, NOT in the release tarballs - so this
shouldn't be a problem, IMO.

> 
> On Mon, 21 Feb 2000, Marc Slemko wrote:
> 
> > Fortunately, it uses a freaky perl path that won't exist on the vast
> > majority of systems.  

True - that should probably be fixed, too.

> > I'm not sure we should be putting CGIs like this in the default doctree
> > anyway... sure, ExecCGI has to be enabled to make it work, but still...

Well, it should never make it into a release tree anyway, and anyone
running CVS builds should presumably know how to fix this??


James.


Re: htdocs/manual/search/manual-index.cgi

Posted by Marc Slemko <ma...@znep.com>.
I don't know that expand.pl belongs is manual/ either.  It isn't great
that any random user can run this from the web if you enable execution of
.pl files; sure, it doesn't let them do so much, but the general
concept...

On Mon, 21 Feb 2000, Marc Slemko wrote:

> This doesn't properly encode its output.
> 
> Fortunately, it uses a freaky perl path that won't exist on the vast
> majority of systems.  
> 
> I'm not sure we should be putting CGIs like this in the default doctree
> anyway... sure, ExecCGI has to be enabled to make it work, but still...
> 
>