<div>Hey Perl Underground,</div>
<div>&nbsp;</div>
<div>Maybe I missed something, could you provide some context around your gripe against RSnake?&nbsp; I&#39;m struggling a bit with it, and your email is quite long and heavily line broken, making it hard to read.</div>
<div>&nbsp;</div>
<div>I&#39;ve found RSnake to be pretty knowledgeable when it comes to web application security, and while I don&#39;t consider myself a fan boy, have respect for him.&nbsp; Perhaps you could take a step back and give us an idea what your general concern is before ripping him?</div>

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