threads / patch / 37997

patchgitweb: hack around CGI's list-context param() handling

Subject: [PATCH] gitweb: hack around CGI's list-context param() handling

## tl;dr

3 messages between Nov 18, 2014 and Nov 18, 2014. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Jeff King· Nov 18, 2014, 17:10 UTC · lore

As of CGI.pm's 4.08 release, the behavior to call CGI::param() in a list context is deprecated (because it can be potentially unsafe if called inside a hash constructor). This cause gitweb to issue a warning for some of our code, which in turn causes the tests to fail.

Our use is in fact _not_ one of the dangerous cases, as we are intentionally using a list context. The recommended route by 4.08 is to use the new CGI::multi_param() call to make it explicit that we know what we are doing. However, that function is only available in 4.08, which is about a month old; we cannot rely on having it.

One option would be to set $CGI::LIST_CONTEXT_WARN globally, which turns off the warning. However, that would eliminate the protection these newer releases are trying to provide. We want to annotate each site as OK using the new function.

So instead, let's check whether CGI provides the multi_param() function, and if not, provide an implementation that just wraps param(). That will work on both old and new versions of CGI. Sadly, we cannot just check defined(\&CGI::multi_param), because CGI uses the autoload feature, which claims that all functions are defined. Instead, we just do a version check.

Signed-off-by: Jeff King <peff@peff.net>
---
Without this patch, all of the gitweb tests consistently fail on Debian
testing/unstable when you have libcgi-pm-perl installed (it works
without that package installed, because an older version of CGI.pm is in
the perl base). I tested with both versions.

Another approach would be to live with the warning, but teach the tests to be less meticulous. I think it probably makes sense to keep them pedantic, though, because it can catch potential errors.

 gitweb/gitweb.perl | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
Show changes to gitweb/gitweb.perl +5 −1
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ccf7516..7a5b23a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -20,6 +20,10 @@ use File::Basename qw(basename);
 use Time::HiRes qw(gettimeofday tv_interval);
 binmode STDOUT, ':utf8';
 
+if (!defined($CGI::VERSION) || $CGI::VERSION < 4.08) {
+	eval 'sub CGI::multi_param { CGI::param(@_) }'
+}
+
 our $t0 = [ gettimeofday() ];
 our $number_of_git_cmds = 0;
 
@@ -871,7 +875,7 @@ sub evaluate_query_params {
 
 	while (my ($name, $symbol) = each %cgi_param_mapping) {
 		if ($symbol eq 'opt') {
-			$input_params{$name} = [ map { decode_utf8($_) } $cgi->param($symbol) ];
+			$input_params{$name} = [ map { decode_utf8($_) } $cgi->multi_param($symbol) ];
 		} else {
 			$input_params{$name} = decode_utf8($cgi->param($symbol));
 		}
-- 
2.1.2.596.g7379948
Junio C Hamano· Nov 18, 2014, 17:58 UTC · re: Jeff King · lore

Re: [PATCH] gitweb: hack around CGI's list-context param() handling

Jeff King <peff@peff.net> writes:
Show 25 quoted lines
> As of CGI.pm's 4.08 release, the behavior to call
> CGI::param() in a list context is deprecated (because it can
> be potentially unsafe if called inside a hash constructor).
> This cause gitweb to issue a warning for some of our code,
> which in turn causes the tests to fail.
>
> Our use is in fact _not_ one of the dangerous cases, as we
> are intentionally using a list context. The recommended
> route by 4.08 is to use the new CGI::multi_param() call to
> make it explicit that we know what we are doing.
> However, that function is only available in 4.08, which is
> about a month old; we cannot rely on having it.
>
> One option would be to set $CGI::LIST_CONTEXT_WARN globally,
> which turns off the warning. However, that would eliminate
> the protection these newer releases are trying to provide.
> We want to annotate each site as OK using the new function.
>
> So instead, let's check whether CGI provides the
> multi_param() function, and if not, provide an
> implementation that just wraps param(). That will work on
> both old and new versions of CGI. Sadly, we cannot just
> check defined(\&CGI::multi_param), because CGI uses the
> autoload feature, which claims that all functions are
> defined. Instead, we just do a version check.

The solution does look like the best in the messy situation. Thanks for looking into it.

Show 16 quoted lines
> +if (!defined($CGI::VERSION) || $CGI::VERSION < 4.08) {
> +	eval 'sub CGI::multi_param { CGI::param(@_) }'
> +}
> +
>  our $t0 = [ gettimeofday() ];
>  our $number_of_git_cmds = 0;
>  
> @@ -871,7 +875,7 @@ sub evaluate_query_params {
>  
>  	while (my ($name, $symbol) = each %cgi_param_mapping) {
>  		if ($symbol eq 'opt') {
> -			$input_params{$name} = [ map { decode_utf8($_) } $cgi->param($symbol) ];
> +			$input_params{$name} = [ map { decode_utf8($_) } $cgi->multi_param($symbol) ];
>  		} else {
>  			$input_params{$name} = decode_utf8($cgi->param($symbol));
>  		}
Jeff King· Nov 18, 2014, 18:01 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb: hack around CGI's list-context param() handling

On Tue, Nov 18, 2014 at 09:58:26AM -0800, Junio C Hamano wrote:
Show 6 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > As of CGI.pm's 4.08 release, the behavior to call
> > CGI::param() in a list context is deprecated (because it can
> > be potentially unsafe if called inside a hash constructor).
> > This cause gitweb to issue a warning for some of our code,
Oops, s/cause/causes/ of course.
-Peff

← back to recent threads