Re^2: Stop Using Perl

in reply to Re: Stop Using Perl
in thread Stop Using Perl

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."

Comment on Re^2: Stop Using Perl

Replies are listed 'Best First'.
Re^3: Stop Using Perl by Anonymous Monk on Jan 05, 2015 at 11:00 UTC
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 [download] 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]
Re^4: Stop Using Perl by leej (Scribe) on Jan 05, 2015 at 12:07 UTC
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]
Re^4: Stop Using Perl by LanX (Saint) on Jan 05, 2015 at 22:31 UTC
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]
Re^3: Stop Using Perl by runrig (Abbot) on Jan 06, 2015 at 17:22 UTC
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]
Re^3: Stop Using Perl by Anonymous Monk on Jan 05, 2015 at 11:23 UTC
Here is a bug report for you, common pitfall `$ perl -MCGI=escapeHTML -le " print escapeHTML(qw/ < < < / ) " <` [download] 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]
Re^4: Stop Using Perl by leej (Scribe) on Jan 05, 2015 at 12:26 UTC
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]
Re^5: Stop Using Perl by LanX (Saint) on Jan 05, 2015 at 23:46 UTC
Thanks for your work maintaining CGI.pm! Thumbs up! CGI.pm helped building the internet and this design to return a list in list context was perfectly OK back then. One can't predict all edge cases and get a project running. And after features are released you're bound to backwards compatibility. It's unfortunate that => wasn't designed as a scalar operator in Perl. And it's also not CGI's fault that methods like `DBI->quote` can't propagate signatures. As I said not all edge cases are predictable. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :)}	[reply] [d/l]
Re^5: Stop Using Perl by Anonymous Monk on Jan 05, 2015 at 22:00 UTC
something constructive! Didn't I just try to do that?	[reply]
Re^6: Stop Using Perl by leej (Scribe) on Jan 06, 2015 at 07:28 UTC
Re^7: Stop Using Perl by Anonymous Monk on Jan 06, 2015 at 08:17 UTC
Re^4: Stop Using Perl by marto (Cardinal) on Jan 05, 2015 at 11:33 UTC
Would it be better to raise issues/provide patches against the github repository (https://github.com/leejo/CGI.pm)? Thanks.	[reply]
Re^5: Stop Using Perl by Anonymous Monk on Jan 05, 2015 at 11:39 UTC
Would it be better to raise issues/provide patches against the github repository (https://github.com/leejo/CGI.pm)? Thanks. Um, don't know, I was kinda ranting ... when the maintainer showed up, so ... ok, maintainer has a point ... if maintainer wants to improve CGI.pm that way, some ideas for maintainer .... ideas probably old news	[reply]
Re^6: Stop Using Perl by marto (Cardinal) on Jan 05, 2015 at 11:41 UTC
Re^4: Stop Using Perl by marjetika (Initiate) on Jul 28, 2015 at 14:57 UTC
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]
Re^5: Stop Using Perl by Anonymous Monk on Jul 28, 2015 at 23:28 UTC
What is the problem with readParse? I've been searching for "readParse vulnerability" all over the internet, and didn't find anything. Why do you care? Read the documentation? Re: Manually add parameters in perl cgi ( no ReadParse no CGI->Vars, ReadParse and Hash Value	[reply]
Re^6: Stop Using Perl by marjetika (Initiate) on Aug 11, 2015 at 18:13 UTC
Re^3: Stop Using Perl by Anonymous Monk on Jan 07, 2015 at 08:48 UTC
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( @_ ); }` [download]	[reply] [d/l]

In Section Perl News