Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Stop Using Perl pt. 2

by Anonymous Monk
on Dec 29, 2015 at 08:20 UTC ( #1151317=note: print w/replies, xml ) Need Help??

in reply to Stop Using Perl pt. 2

Hashes and arrays are considered "secure" (???)

probably thinking of buffer overflows

but it seems like this talk is more productive.

What does that mean "productive"?

You take old information (not news) and use it to for self-promotion and ... inspire comments like

SebastianMisch 6 hours ago Great talk. I had a big laugh. I watched the previous talk and those two talks have definitely taught me to stay as far away from Perl < 6 as possible.? ·

lathiat 5 hours ago I was looking forward to this talk badly after last years, and boy we were in for a treat. This guy is a great presenter, on top of great content. Highly entertaining and informative.?

Productive? Um, yeah, sure

Replies are listed 'Best First'.
Re^2: Stop Using Perl pt. 2
by Anonymous Monk on Dec 29, 2015 at 09:20 UTC

    Netanel Rubin cannot resist embarrasing himself :)

    Published on Dec 28, 2015

    The Perl Jam 2
    The Camel Strikes Back


    After last year’s Perl crackdown, I decided I have to take the Perl abuse to the next level. This time I focused on Perl’s core, or more specifically, the referencing mechanism, and shattered the security of most Perl CGI projects in the world.

    With more WATs, more broken concepts, and more wildly popular 0-days, we will finally prove the Perl language is a broken concept, one that stood tall for way too many years.

    Presenting „The Perl Jam: Exploiting a 20 Year-old Vulnerability“ at 31c3 opened a Pandora’s Box full of Perl debates and controversies. Many of these debates originated from the Perl community itself, with unforgiving arguments such as „vulnerabilities are the developer’s fault“, „RTFM“ and „I really hate the Camel abuse in the presentation“ that were mostly directed at me.

    This is why I’m proud to say that this year I finally got the message: Finding vulnerabilities in core modules is not enough. I need to prove there are problems in the most fundamental aspects of the Perl language, or the Perl community will keep ignoring the language many issues.

    So I did, and we are going to analyze it in a presentation filled with lolz, WATs, and 0-days, so maybe this time something will change.

    Join me for a journey in which we will delve into more 0-days in Bugzilla, an RCE on everyone who follows documentation, and precious WTF moments with basically any other CGI module in the world, including (but not limited to) Mojolicious, Catalyst and PSGI, affecting almost every Perl based CGI application in existence.

    I hope this talk will finally prove that developers are NOT the fault here, it’s the LANGUAGE, and its anti-intuitive, fail-prone ‚TMTOWTDI‘ syntax. btw, maybe it’s time to check your $$references ;)

    ➤Speaker: Netanel Rubin
    ➤EventID: 7130
    ➤Event: 32th Chaos Communication Congress 32c3 of the Chaos Computer Club CCC
    ➤Location: Congress Centrum Hamburg (CCH); Am Dammtor; Marseiller Straße; 20355 Hamburg; Germany
    ➤Language: english
    ➤Begin: Mon, 12/28/2015 20:30:00 +01:00

      ..embarrasing himself

      It is arrived the time to make English a better language? In Castellano there is a precious concept: vergüenza ajena
      Deutsch altready upgraded with the fremdschämen neologism.

      I dont think 'embarassing himself' it's enough: can other's shamefulness rend better the concept?

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
        huh? can you translate whatever you're saying in simple english?
Re^2: Stop Using Perl pt. 2
by Anonymous Monk on Dec 29, 2015 at 09:07 UTC
Re^2: Stop Using Perl pt. 2
by sushi (Initiate) on Dec 29, 2015 at 14:21 UTC

    Actually, by "hashes and arrays are considered secure", he meant that Perl developers do not consider hashes, arrays, or elements of either to be controlled by user input - not requiring sanitation.

    By 'productive' I meant that he actually found some serious gotcha's rather than complaining about basic language features. Like, I had no idea about <$file> when $file is actually ARGV or whatever he went on about.

      Even if you use the relatively safe three-argument version of open, you need to sanitize the user input. Ideally, you would never use user input to open a file or pass user input to an operating system function, which is where open basically ends up at. If you open files from user input and don't use three-argument open, you get what you deserve. This is documented in I/O Operators, but maybe not in such direct words.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1151317]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (2)
As of 2020-10-25 23:47 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (249 votes). Check out past polls.