Change the param() interfac?

[Dylan Hardison]

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.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=555438
[2] https://metacpan.org/pod/Hash::MultiValue (also available via ActiveState ppm)

----- Original Message -----
From: "Damien" <damien.nozay at gmail.com>
To: developers at bugzilla.org
Cc: dev-apps-bugzilla at lists.mozilla.org
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 mozilla.org> wrote:

> Hi everyone,
>
> As you know, we have just done a security release. The bug is written up
> here:
>
> http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/
>
> I have been pointed at this article from 5 years ago:
>
>
> http://bulknews.typepad.com/blog/2009/12/perl-why-parameters-sucks-and-what-we-can-do.html
>
> 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/CGI.pm) 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 lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=damien.nozay@gmail.com>
>
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dylan@mozilla.com>