Change the param() interfac?

Dylan Hardison dylan at
Wed Oct 15 20:52:02 UTC 2014

There is Perl::Critic, although it may not have caught the param() in list context problem, it may be able to catch other problems.
I've had some discussion with LpSolits about this, and I've re-opened Bug 555438[1] to craft
a perl-critic configuration that meets the needs of the project.

With regards to the specific problem $cgi->param(), there are many solutions we could follow.
One typical solution is Hash::MultiValue[2], which was written specifically because of the param() in list-context fault.

[2] (also available via ActiveState ppm)

----- Original Message -----
From: "Damien" <damien.nozay at>
To: developers at
Cc: dev-apps-bugzilla at
Sent: Tuesday, October 7, 2014 1:08:29 PM
Subject: Re: Change the param() interfac?

Hi folks,
isn't there some kind of perl lint tool to tell you these kinds of
constructs are bogus & dangerous?

On Tue, Oct 7, 2014 at 1:06 AM, Gervase Markham <gerv at> wrote:

> Hi everyone,
> As you know, we have just done a security release. The bug is written up
> here:
> I have been pointed at this article from 5 years ago:
> which agrees that the param() interface is not awesome, although it
> doesn't cover the security concerns we now know it raises. It seems that
> many frameworks don't like this way of doing things, and have come up
> with alternatives which are less of a footgun. The article documents
> several alternatives, of which I think the leading two are:
> 1)
> $cgi->param('foo') always returns scalar
> $cgi->arrayparam('foo') always returns a list
> 2)
> $cgi->scalarparam('foo') always returns scalar
> $cgi->arrayparam('foo) always returns array
> $cgi->param('foo') throws an error to stop you using it and make you
>                    make a specific decision
> (Let's not bikeshed on the function names before we've chosen an approach.)
> I strongly think the best way to avoid future security holes is to make
> the pattern which leads to them impossible. I know we now have a test to
> detect the particular pattern which caused these bugs, but I'm not
> willing to bet any money that there aren't other places or ways or
> contexts this could happen. So I think we should switch the Bugzilla
> codebase over to one of these two patterns, using the fact that we
> control the CGI object (Bugzilla/ to alter the behaviour of the
> functions.
> I know LpSolit has expressed reservations, and that dveditz (Mozilla
> security guy) is in favour. Comments?
> Gerv
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at
> -
> To view or change your list settings, click here:
> <>
dev-apps-bugzilla mailing list
dev-apps-bugzilla at
To view or change your list settings, click here:

More information about the developers mailing list