Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Perl Underground speaks
From: "Nate McFeters" <nate.mcfeters () gmail com>
Date: Thu, 10 Apr 2008 22:05:09 -0500

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.


On 4/10/08, auto263090 () hushmail com <auto263090 () hushmail com> wrote:

This is Perl Underground here. We thought we could respond to a
kids, cause there ain't nothin' like dissin' on FD. Part of this
is just in general, and might end up in Perl Underground 6. So it's
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
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,
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
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
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

"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
keep it turned on?"

I bet the people you know who write code for a living are shit with
too. The warnings pragma (*not* just the -w flag, there are slight
differences in practice but that's getting beyond you and offtopic)
highly useful in debugging AND in released code. Why? Because it
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
fuck would you leave it in if you had the impression that even
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
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-
reasons that apply to warnings as well. The actual performance hit
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
have been slowly added and will continue to be added with future
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
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
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

We saw both the beta and the 1.0, and both times thought the code
You labelled 1.0 as a "production ready DNS enumeration tool".
Maybe we
just have higher standards than you for production-ready. Frankly,
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
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
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
is needed for average users to increase their security. We discuss
better education is needed for the pure mass of programmers,
those with blogs and fanboys, to increase the stability of our
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

We have a strong commitment to quality Perl code and doing our part
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
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
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!


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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]