http://www.perlmonks.org?node_id=1151309

The Perl Jam 2: The Camel Strikes Back (32c3) https://www.youtube.com/watch?v=eH_u3C2WwQ0

Link to discussion of last year's talk: 1111750

I cringed the first talk, but it seems like this talk is more productive. Summary:

I sincerely hope there will not be a Stop Using Perl pt 3. I can only handle someone complaining about list flattening for so long.

Replies are listed 'Best First'.
Re: Stop Using Perl pt. 2
by choroba (Cardinal) on Dec 29, 2015 at 23:21 UTC
    Link to Kent Fredric's analysis of the talk (found in the YouTube discussion).
    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
      Cool the analysis saved me from watching "Nathanial the Jammer" again! =)

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Je suis Charlie!

Re: Stop Using Perl pt. 2
by CountZero (Bishop) on Dec 29, 2015 at 18:41 UTC
    An ignoramus speaking to his sycophants. Not even worth to click the youtube link.

    The C-language makes it so easy to have buffer overflows that are arguably the source of multi millions of damage. So let's trash C and go back to the good old slide rule and pencil and paper.

    Any programmer worth his salt can write bad code in any language.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
Re: Stop Using Perl pt. 2.. mwhaahaha!!
by Discipulus (Canon) on Dec 29, 2015 at 08:39 UTC
    if I say: "Let's the dog down that i'll piss him" means that English is a crappy language?

    Permanent answer to ALL PEOPLE THAT DOES NOT LIKE PERL: dont use it but please dont break my balls anymore.

    response to Perl jam 2 at blogs.perl.org

    L*
    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.
Re: Stop Using Perl pt. 2
by Tanktalus (Canon) on Sep 03, 2016 at 18:52 UTC

    His basic, most fundamental flaw, was simple.

    He complained, "Why don't perl improve?" near the end. It was his conclusion - perl is crap because it "don't improve (sic)." And he proved this lovely little theorem by testing the "popular" and massively outdated modules. I don't care what language you write your web service in, if you use models and libraries that are not current, you're going to have problems.

    He complained that perl hasn't improved based on the fact that his choice of targets were outdated. WAT is right.

    There were other problems, to be sure, but this one is so fundamental that the rest of his flaws are really quite minor, relatively speaking. Basically, he just told us that Java 1.2 is insecure, and that everyone should stop using Java 8 because of that.

    And this passes for security research? Maybe in his little corner of the world, but any serious security researcher would be embarrassed by such a conclusion from such irrelevant evidence.

Re: Stop Using Perl pt. 2
by BrowserUk (Patriarch) on Dec 29, 2015 at 06:17 UTC
    Published on 28 Dec 2015

    Published to Utube yesterday, just in time for your post? Did you publish it? If not, man you've got your finger on the pulse.

    If so, why do you (and how much did you pay?) attend talks where they allow cantankerous children like this to speak? Twice!


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
      I watched both talks on YouTube - not in person. I have not attended CCC and do not have any affiliation with CCC or the speaker. Just another annoyed monk.
Re: Stop Using Perl pt. 2
by Anonymous Monk on Dec 29, 2015 at 08:20 UTC

    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

      Netanel Rubin cannot resist embarrasing himself :)

      Published on Dec 28, 2015

      The Perl Jam 2
      The Camel Strikes Back

      tl;dr EXPLOIT ALL THE PERL. AGAIN.

      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 CGI.pm 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?

        L*
        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.

      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.