|
Re^2: Stop Using Perl
by shmem (Chancellor) on Dec 30, 2014 at 20:47 UTC
|
Bugs being addressed that fast is another reason for not to stop using such a bizarre language.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |
Re^2: Stop Using Perl
by leej (Scribe) on Jan 05, 2015 at 09:51 UTC
|
You contradict yourself. You say the talk is embarrassing (and it is), that it's amazing that CGI.pm was patched to warn about this; then you complain that CGI.pm is "about to get real stupid" by breaking backwards compatibility. Do you not see the contradiction? Sometimes we have to break backwards compatibility to fix issues like this, and the "real stupid" thing is to turn a blind eye and say "well, it's legacy code so fuck it". Doing *that* gives Netanel Rubin, et al, even more fuel for their FUD.
The fix highlighted in your post only breaks back compatibility for those with fatal warnings enabled - arguably those users with fatal warnings enabled are the most concerned about problems like these. As i've previously stated - v4 releases of CGI.pm will be back compatible (as much as can be when issues like this arise). v5 and beyond *may* not be. CGI.pm is no longer core and Lincoln has trusted me to DTRT. Regarding the v5 releases: "I am altering the deal, pray I don’t alter it any further."
| [reply] |
|
|
You say ... that it's amazing
I'm fairly certain that what the other anon meant is "<sarcasm>amazing</sarcasm>", in which case he/she isn't contradicting him/herself.
The fix highlighted in your post only breaks back compatibility for those with fatal warnings enabled
No, at least not as of 4.13; the warning is unconditional and not fatal:
$ perl -MCGI -sE 'say $CGI::VERSION'
4.13
$ perl -MCGI -E 'no warnings; my $x=CGI->new; $,=", ";
say $x->param("x"); say "didnt die"' -- x=foo x=bar
CGI::param called in list context from package main line 1, this can l
+ead to vulnerabilities. See the warning in "Fetching the value or val
+ues of a single named parameter" at /opt/perl5.20/lib/site_perl/5.20.
+0/CGI.pm line 437.
foo, bar
didnt die
$ perl -MCGI -E 'use warnings; my $x=CGI->new; $,=", ";
say $x->param("x"); say "didnt die"' -- x=foo x=bar
CGI::param called in list context from package main line 1, ...
foo, bar
didnt die
$ perl -MCGI -E 'use warnings FATAL=>"all"; my $x=CGI->new;
$,=", "; say $x->param("x"); say "didnt die"' -- x=foo x=bar
CGI::param called in list context from package main line 1, ...
foo, bar
didnt die
Assuming you're the current maintainer: if you want warnings that the user of CGI can enable, disable and make fatal themselves, you should be using warnings::warnif() with warnings::register instead of warn.
BTW, 4.13 is showing up on search.cpan.org as an unauthorized release.
| [reply]
[d/l]
[select] |
|
|
I don't see the sarcasm in the original post, but fair point.
Yes, i still haven't received permissions updates for the Fh back compat module (which used to be embedded in CGI) and MultipartBuffer embedded package within CGI so the release shows as unauthorized (and yes, i've contacted the necessary people, just not chased yet).
Warnings not being fatal is my error, i'd seen this as an issue in twiki so i guess they had something else making the warnings a problem; i'll leave this as is since it will retain the back compatibility behaviour, and will look at warnings::register, thanks!
| [reply] |
|
|
Actually your test reveals how during this talk the highscore in bullshit bingo was finally broken.
At the question section Rubin - after being asked how the Perl maintainers reacted - said something along the line
"oh they activated something called Warnings ...after you attacked the system you get a warning that you just attacked the system" and rolled his eyes.
Truth is whoever writes an application ever using param() in list context gets warnings, from the first moment the code is executed.
No matter if there were any multi values in the request or anyone tried to break in.
Whoever upgrades gets a warning after his first test run.
That's pretty strict.
Cheers Rolf
(addicted to the Perl Programming Language and ☆☆☆☆ :)
| [reply] |
|
|
You contradict yourself. You say...it's amazing that CGI.pm was patched...
Definitions/usages of amazing include the notion of being "struck with some degree of horror". I see no contradiction.
| [reply] |
|
|
$ perl -MCGI=escapeHTML -le " print escapeHTML(qw/ < < < / ) "
<
Also, why not warn about html shortcuts getting used?
Also, another pitfall you might be able to warn about in some cases, mixing exported param() with CGI->new ?
Also, why not warn about header_printed ? (you already printed headers, second time doesn't count)
And big one, warn about anyone using using ReadParse/->Vars
:) | [reply]
[d/l] |
|
|
I'm happy to receive bug reports, comments, patches, pull requests (with tests), etc at the github repo page: https://github.com/leejo/CGI.pm/issues. Please don't rant though, there's 20 years of history in this module that pre-dates my maintenance involvement. Turn the rant(s) into something constructive!
| [reply] |
|
|
|
|
|
|
|
|
|
| [reply] |
|
|
|
|
|
|
quote: And big one, warn about anyone using using ReadParse/->Vars
What is the problem with readParse?
I've been searching for "readParse vulnerability" all over the internet, and didn't find anything.
| [reply]
[d/l] |
|
|
|
|
|
|
Seem odd to have to force scalar context to get a single_value .. there should be a function for that
sub CGI::first_param { return my( $first ) = param( @_ ); }
sub CGI::last_param { return my $last = param( @_ ); }
| [reply]
[d/l] |
Re^2: Stop Using Perl
by Anonymous Monk on Dec 30, 2014 at 20:58 UTC
|
| [reply] |
