Re: [PATCH v5.5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Jakub Narebski <hidden>
Date: 2016-06-15 22:52:53
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...
quoted hunk ↗ jump to hunk
@@ -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