Message-Id: <20080411005203.36E4420044@mailserver7.hushmail.com>
Date: Thu, 10 Apr 2008 20:52:01 -0400
From: <auto263090@...hmail.com>
To: <full-disclosure@...ts.grok.org.uk>
Cc: 
Subject: Perl Underground speaks

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/

Powered by blists - more mailing lists