Re: [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 11 May 2010, Peter Vereshagin wrote:
> 2010/05/11 12:58:50 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :

> > > > I have changed this 'exit' to non-local goto to toplevel.  It could be
> > > > done instead by redefining 'exit' subroutine, like shown below, but I
> > > > feel that would be hacky if you can change gitweb code (it is not
> > > > black box you should not touch).
> > > 
> > > Right, one shouldn't ever redefine perl built-in functions. I did only because
> > > of no other way to 'get things working'
> > 
> > Why not?  For example CGI::Carp redefines 'die' to log errors.
> 
> Ouch, sorry, I meant 'last' or something like that.

"last" / "last LABEL" is a command, not a function, therefore you cannot
redefine it.

Well, perhaps you can with heavy hackery involving opcodes and the like,
or something debugger-like, or/and something like B::* modules, taking
over Perl parser.  See e.g. Devel::Declare or Template::Declare Perl
modules on CPAN. :-)

> I just believe any non-system application development for end-user being a
> non-developer doesn't need to redefine perl built-in functions. Just a sane
> bone tone for common functioning in a sandbox.
>
> For example, I remember the Linux kernel  ( or Glibc? ) was criticised much of
> being possible to override the str*cmp() inside. Because most of the existing
> commerceware were protected from copying by password, e. g. serial number, etc.
> sometimes by authors. So criticants supposed it's impossible to 'protect' their
> software this way. And thus Linux was 'bad'. ;-)

What about libsafe (?) and similar security solutions, which replace
str* functions from (g)libc with safer but slower counterparts?  What
about Dmalloc, Electric Fence and the like which replace malloc etc.?

> So one who use CORE:: namespace in their sources should always know it can be
> grepped and considered as dangerous, especially if those are 3rd+ party
> sources, not approved by any reasonable authority, and there are lots of such a
> software off the shelves to choose. And most of them doesn't use to override
> perl built-in functions. ;-)

It is true that messing with / overriding things from CORE:: (or
UNIVERSAL:: for OOP) namespace is dangerous, and should be avoided if
possible... but well, sometimes it is a best solution.
 
> > I know this from painful experience of trying to find bug in a
> > test... when the error was in parsing file in 'do $file;'.
> 
> I handle them just fine like in any other CGI program using
> CGI::Carp:fatalsToBrowser. Are you about to 'make test' via the http? ;-)

I don't think you understand what I wanted to say there.

If you don't check if there were parse errors from 'do $file;', you can
get later some error message which is totally unrelated to the parsing
error.  If you don't know or forget that you should check $@ after 
'do $file;', and are unlucky, you can chase elusive error from there
to kingdom come...

For example when debugging gitweb output caching code using automated
tests, I got the following error:

  'Undefined subroutine &GitwebCache::SimpleFileCache::compute called'

The subroutine was defined, but there was a bug in parsing included
file, so Perl didn't make it to definition of said compute() subroutine.

> [...]
> 
> >   builder {
> >         $app;
> >   }
> 
> that's the wow to try. I will after some of my whiles.

Check out http://plackperl.org, especially presentations and Perl Advent
Calendar which describes PSGI/Plack step by step (links at the bottom of
the page).
 
> > or even without it ($app should be the last expression).
> > Or did you mean here something like mod_rewrite, or
> > Plack::Middleware::Rewrite?
> 
> No, nginx rewrites just fine, it's a matter of another application level I
> believe.
>
> The scoop is meat and potatoes: here is the CGI app, just do it over FastCGI.
> There are no such a thing as a mandatory mounts and paths tweaks in PHP's
> FastCGI. Hope PSGI has no them either.

PSGI is interface, Plack is reference implementation.  You can run PSGI
app on any supported web server; this includes running PSGI apps on
FastCGI.

> > > > Gitweb doesn't use no POST requests: it is read-only web repository
> > > > browser... well, except for the 'show_ctags' action.
> > >
> > > Tag cloud? Is there an example of usable tag cloud on any public gitweb out
> > > there?
> > 
> > Tag cloud are optional feature in stock gitweb, named 'ctag' in %feature
> > hash.  It is disabled by default.  If I understand correctly POST is
> > used here to populate which tags one wants to use... but perhaps GET
> > request would be enough here (at the cost of less readable URL).
> > 
> > See http://repo.or.cz for example usage of this feature.
> 
> Ouch, it was the first for me to look for them. It's just not named like that
> there ( and looked like linkspam ;-. Anyway. user registration .cgi is a part
> of gitweb distribution? It contains POST form and it's not  preferable stuff to
> omit for too many cases to consider such a gitweb-based web site to be 'mostly
> read-only' for a user.
>
> Or those .cgi's are nothing in common with gitweb?

The repository management part of http://repo.or.cz is not part of
gitweb.  It is a separate tool, named Girocco.

-- 
Jakub Narebski
Poland