Re: Perl Underground speaks

["Nate McFeters" <nate.mcfeters () gmail com>]

Hey Perl Underground,

Maybe I missed something, could you provide some context around your gripe
against RSnake?  I'm struggling a bit with it, and your email is quite long
and heavily line broken, making it hard to read.

I've found RSnake to be pretty knowledgeable when it comes to web
application security, and while I don't consider myself a fan boy, have
respect for him.  Perhaps you could take a step back and give us an idea
what your general concern is before ripping him?

I may have missed something in a previous email, just not seeing anything
concrete in your message.

Nate


On 4/10/08, auto263090 () hushmail com <auto263090 () hushmail com> wrote:
> This is Perl Underground here. We thought we could respond to a
> couple
> kids, cause there ain't nothin' like dissin' on FD. Part of this
> rant
> is just in general, and might end up in Perl Underground 6. So it's
> to
> be considered BETA, and thus criticism is UNACCEPTABLE!!!
>
> Just kidding.
>
> RSnake and his talentless fanboys would like to diss Perl
> Underground in
> any way he can to mend any damage to his image. He likens us to Perl
> programmers he has schooled on security topics. This may mend his
> ego, but
> does not reflect accurately on the people of Perl Underground nor
> does it
> help understand the Perl issues we brought forth. RS wants to give
> the
> impression that he is an incredibly talented individual (a "Web
> application security god") who has, without reason, been maliciously
> targetted for a year by Perl programmers who must be untalented,
> otherwise
> they would be public. Nevermind that we critiqued many others, or
> that we
> connect readers with more positive information than poor code.
> Nope, we
> must be all about RSnake jealously.
>
> IceShamen claims we "pedantically analysed everything line for
> line" while
> RS states "I don't have a year to debug a small program, like
> apparently
> he does".
>
> A contributor spends maybe twenty minutes going over code of this
> size. We
> stated explicably in past zines that we are merciful and only
> discuss the
> occasional issue. Until you actually learn Perl, RSnake, it's
> hardly worth
> our time to teach you Perl OOP or proper documentation technique
> (what you
> call "Perldoc" is generally called "POD", by the way, but
> whatever). We do
> not intend to fix your code. Instead we simply offer the occasional
> suggestion to make you think. You two are responsible for your own
> code,
> it isn't our fault there are so many issues that we can only
> discuss (and
> notice, for that matter) a certain amount in a given publication
> size.
>
> "and the -w flag? Most people I know who write code for a living
> only turn
> that on while debugging. Once you put it into production why would
> you
> keep it turned on?"
>
> I bet the people you know who write code for a living are shit with
> Perl
> too. The warnings pragma (*not* just the -w flag, there are slight
> differences in practice but that's getting beyond you and offtopic)
> is
> highly useful in debugging AND in released code. Why? Because it
> catches
> runtime problems, fuckhead. There might be no warnings in your last
> set of
> tests, but different data can provoke them and reveal errors in
> your code.
> Lots of serious professional Perl programmers INSIST on warnings
> being on.
> On the other side of your argument, strict is compile-time, so why
> the
> fuck would you leave it in if you had the impression that even
> warnings
> was of no further use to you? strict is much less likely to make a
> difference to you if it passes in general, which is ironic given
> your
> position on warnings. Again, in practice Perl coders leave strict
> in to
> save time maintaining (instead of setting it again for every patch)
> and as
> a clear sign that the code is strict-safe and the author strict-
> aware,
> reasons that apply to warnings as well. The actual performance hit
> of
> either is unnoticable, certainly not a bottleneck in your program.
>
> "[...] changing the scope from global to local doesn't change how
> the code
> works - at all. Not to mention there are dozens of missing features
> that
> have been slowly added and will continue to be added with future
> revisions,
> so cleaning it up now doesn't make a lot of sense since it's
> getting a
> complete re-write anyway"
>
> Isn't that smart? Let's leave it as a total mess because we're just
> going
> to add more to it and make it a further mess? How about you get
> your code
> under control and maintain it. Or are you just too used to writing
> little
> piece of shit programs, that you do not have the organizational
> skills to
> manage a slightly-larger little piece of shit program with multiple
> contributors? How about you exclusively use file-scoped variables
> in C
> programs, because various shitheads aren't smart enough to design
> procedural code and you cannot figure out how to responsibly
> organize it?
> That probably sounds ridiculous, but that's the argument that
> RSnake is
> making.
>
> We saw both the beta and the 1.0, and both times thought the code
> sucked.
> You labelled 1.0 as a "production ready DNS enumeration tool".
> Maybe we
> just have higher standards than you for production-ready. Frankly,
> your
> code is shit, regardless of which version we criticize. You can hide
> behind the fact that we wrote about 0.9.9 instead of 1.0, but only
> so much
> changed. It's still shit, so is 1.0.3.
>
> Hardly anything has changed in the meantime, and it is no less
> enlightened.
> Almost everything shitty ("style") complaint, like, uh:
>
> if ($filename && $filename ne '') {
>
> are still around. Mostly it has just been moved around. Fresh shit
> has been
> added. Consider these two consecutive lines:
>
>     $domain =~ s/\.$//g;
>     my $inet = inet_aton("$domain");
>
> Not cool RSnake, not cool.
>
> We are a collection of individuals who come together under an
> understanding. This understanding is that most programmers write
> code that
> is less than mediocre, and that concrete steps need to be taken to
> increase our standards at all levels. This is virtuous for both
> artistic
> and pratical reasons. Some do this in peaceful ways (and even we
> do, too,
> through other avenues), while we felt a need for more vocal
> protests. Many
> self-described security gods calmly discuss how better computer
> education
> is needed for average users to increase their security. We discuss
> how
> better education is needed for the pure mass of programmers,
> including
> those with blogs and fanboys, to increase the stability of our
> software
> infrastructure in both the short and long term. Every time a piece
> of bad
> software is distributed it damages this longterm goal for all of
> us. We do
> not expect perfect code (we certainly do not write perfect code),
> but we
> do expect basic research and at least mediocrity before
> distribution.
>
> We have a strong commitment to quality Perl code and doing our part
> to
> support the production and release of the best Perl possible.
> That's why
> if you release something, you better be able to take a bit of heat.
> We let
> a lot of code go that would not pass a basic code review at any
> respectable establishment, and instead we stick to noticably loud or
> shitty code.
>
> You wrote and published bad code, RS. Just as you can be rewarded
> for
> writing a moderately useful tool, you can be criticized for
> defecating on
> our art.
>
> We are anonymous because we have no need not to be. Being anonymous
> leaves
> our articles up for review publicly, instead of just providing
> names for
> you to attack ad hominem, although you tried anyways. Perl
> Underground is
> not about improving our programming careers. It is not about making
> a name
> for ourselves in security communities. It is not about having
> fanboys. It
> is not about having a blog, forum, or advertisements.
>
> It's about Perl.
>
> --
> Click here for great computer networking solutions!
>
> http://tagline.hushmail.com/fc/Ioyw6h4fM6mtFdSymaRUi4nQIA5KxMxTHHZDKMZ4J8r8h0yR0j27LC/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/