[Koha-bugs] [Bug 15809] versions of CGI < 4.08 do not have multi_param

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Feb 17 14:43:48 CET 2016


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15809

--- Comment #7 from Jonathan Druart <jonathan.druart at bugs.koha-community.org> ---
(In reply to Marcel de Rooy from comment #5)
> I am having the impression that we do not completely tackle the problem
> (read vulnerability given) here.
> Because just switching param to multi_param (without looking to the context)
> does not really solve it. You only suppress the warning.

Yes of course, but we are now aware of this problem, and it's the QA's job to
catch them if they are wrongly used.

> Redefining methods/routines for lower versions of a module is not the most
> elegant solution (from QA perspective). If we could prevent doing so, we
> should. 
> Since we do not need to add calls to multi_param yet and we do not address
> the actual vulnerability in this patch, I would propose to not add this
> redefinition. We should concentrate on the calls to param in a hash context
> and scalarize them. (The warnings in the log show us where these calls are.) 

The goal was to remove the warnings for production installs using CGI < 4.08.
As a developer, I am using > 4.08 and will see the warnings in my logs.

(In reply to Marcel de Rooy from comment #6)
> Still we have the other situation that we do want multiple values:
> my @a = param( 'b' );
> 
> Should this actually be solved in CGI? It generates a lot of false warnings.
> For reasons of compatibility param cannot just return a scalar.

How do you want to fix that, I don't think I understand what you meant here.

> Would it be simpler to only clear $CGI::LIST_CONTEXT_WARN for individual
> cases?

I don't think so, developers won't see the warnings, we should keep them to
know where the issues could come from.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list