Re: [PATCH v5.5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 30 Jul 2012, Bernhard R. Link wrote:

> Use of the filter option of git_get_projects_list is currently
> limited to forks. It hard codes removal of ".git" suffixes from
> the filter and assumes the project belonging to the filter directory
> was already validated to be visible in the project list.
> 
> To make it more generic move the .git suffix removal to the callers
> and add an optional argument to denote visibility verification is
> still needed.

Even better for patch readability would be to split this patch further,
with the first part just moving removal of ".git" suffix from said
function to callers.
 
> If there is a projects list file (GITWEB_LIST) only projects from
> this list are returned anyway, so no more checks needed.
> 
> If there is no projects list file and the caller requests strict
> checking (GITWEB_STRICT_EXPORT), do not jump directly to the
> given directory but instead do a normal search and filter the
> results instead.
> 
> The only (hopefully non-existing) effect of GITWEB_STRICT_EXPORT
> without GITWEB_LIST is to make sure no project can be viewed without
> also be found starting from project root. git_get_projects_list without
> this patch does not enforce this but all callers only call it with
> a filter already checked this way. With this parameter a caller
> can request this check if the filter cannot be checked this way.

O.K. now I see where the "paranoid mode" might make difference: if
one of intermediate directories in $project_filter subdirectory has
search/access permission ('x' bit) but is not readable ('r' bit),
then gitweb would show nothing in $strict_export mode, but scan from
"$projects_list/$project_filter" in non-strict mode.

Perhaps there are other cases...
 
> @@ -2841,7 +2840,7 @@ sub git_get_projects_list {
>  		my $pfxlen = length("$dir");
>  		my $pfxdepth = ($dir =~ tr!/!!);
>  		# when filtering, search only given subdirectory
> -		if ($filter) {
> +		if ($filter and not $paranoid) {

Hmmmm... ($filter and !$paranoid) or ($filter && !$paranoid)?
Which would be more Perl-ish and fit current code style better...

-- 
Jakub Narebski
Poland