[Security] Breaking changes in Mojolicious 5.48

[sri]

You might have heard about this recent Bugzilla exploit.

    http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/

It is not exactly a new attack vector.

    http://seclists.org/vulnwatch/2006/q4/6

We've described these kinds of attacks in the documentation for some time now and were planning to change the API in a future major release.

    https://github.com/kraih/mojo/blob/v5.47/lib/Mojolicious/Controller.pm#L568-L586

But with the amount of attention this attack vector has gotten recently, and the frightening number of vulnerable Mojolicious plugins on CPAN, we've come to the conclusion that waiting is simply not an option anymore. So in Mojolicious 5.48, which i've just released, we are making a few simple but breaking changes.

    https://github.com/kraih/mojo/compare/v5.47...v5.48#diff-c112bb3542e98308d12d5ecb10a67abcR2

We do not expect too much breakage, since intentional use of these methods in list context is rare, but a few of you will be affected.

    my @values  = $c->param('foo');

    my @values  = $c->cookie('foo');

    my @values  = $c->signed_cookie('foo');

    my @values  = $c->req->param('foo');

    my @cookies = $c->req->cookie('foo');

    my @uploads = $c->req->upload('foo');

would become: (yes, i'm using the Perl 5.20 postderef syntax!)

    my @values  = $c->every_param('foo')->@*;

    my @values  = $c->every_cookie('foo')->@*;

    my @values  = $c->every_signed_cookie('foo')->@*;

    my @values  = $c->req->every_param('foo')->@*;

    my @cookies = $c->req->every_cookie('foo')->@*;

    my @uploads = $c->req->every_upload('foo')->@*;

And you've got one less attack vector to worry about in the future, "wantarray" is gone from the Mojolicious code base for good.

P.S.: I've also modified our deprecation policy to make it easier for us to react to these kinds of emergencies. If you feel this is wrong, you're welcome to start a discussion.

    https://github.com/kraih/mojo/commit/193541fe9d256782f3d8396a0a6012a470695b65

--

sebastian

[Stefan Adams]

On Tue, Oct 7, 2014 at 6:52 PM, sri <kra...@googlemail.com> wrote:

I've also modified our deprecation policy to make it easier for us to react to these kinds of emergencies. If you feel this is wrong, you're welcome to start a discussion.

I figured such a policy in regards to security issues goes without saying.  :)  Nevertheless, I'm glad you're more clear about it!!