Well, in Part 1, I promised to explain why I went back to Groovy after ignoring it for so long. But to explain that would be to explain a whole bunch of other stuff. While not completely security related, it might be interesting for developers to see the thought process that makes a wishy-washy person like me jump ships on languages.

First, I’m not a religious zealot about languages. To me, languages are just tools, and learning a new language is a matter of learning syntax, and how to find the libraries I need to do the job.

For the longest time, I was a Perl coder - er….line noise coder. My code was write-only. In Java parlance, write once, ignore forevermore. The two major benefits of perl for me were availability of libraries and documentation for those libraries (owing to perl’s maturity), and syntactical sugar. (Of course, I didn’t know the benefits of the second until I couldn’t use it anymore).

I used perl a lot. But for pen testing, I kept coming into situations where it wouldn’t cut it anymore - almost always due to finicky proxy requirements. I could do SSL, I could do proxy, I could do NTLM autentication, but I always seemed to have issues dealing with combinations of the three. And it seemed that many, many pen tests had something come up that required some scripting and that the tools out there simply couldn’t handle.

So for one assessment I tried out Commons HttpClient with Beanshell. I had been using Java and Struts for web development for awhile, so the transition to Beanshell was natural. And HttpClient did exactly what I needed when I couldn’t seem to make Perl do it. (My apologies to the perl people for giving up so easily, but I had an immediate need. And my apologies to the Python people because I prolly never gave Python a fair shake).

So I stuck with beanshell and HttpClient for awhile. But beanshell never really made me happy. While a dynamically-typed java was nicer, it never got to feel like a scripting language because I still didn’t have a lot of syntactical sugar. My colleagues jumped on the Ruby bandwagon quickly, and I jumped off as quickly because the two things I needed to be able to do with it were difficult to find libraries for. And in fact, did a lot of assessment work where I’d use beanshell to do the http plumbing, and perl to do the parsing because parsing HTML in Java is so un-natural - possible, but not natural.

I’m not sure why I gave up on groovy so long ago. I’m not sure why that one afternoon I dusted off beanshell instead of dusting off groovy, but I wish I had picked groovy then. A couple of weeks ago, I decided to look at groovy again when I had had enough with beanshell, and I was floored. It was like magic. All the library maturity of Java (I still get to use Jakarta stuff) with all the syntactical sugar of perl and all the readability of Ruby. And that there are builders for almost anything hierarchical in nature.

– Sylvan von Stuppe

Tags: Sylvan von Stuppe

Many of my colleagues are (as is a lot of the web development world) really high on Ruby on Rails. And I can understand why. Really cool Web 2.0 sounding statements like “convention over configuration” or DRY (Don’t Repeat Yourself - which I just did by telling you what the acronym meant right after the acronym) are not just words, they’re baked in to the way Rails operates. Rails makes the every day of web application development uber-easy. And heck, Ruby has closures which almost any legitimate scripting language really needs.

But I’ve always had some problems with Rails. Some of these are admittedly probably based on my fear of change, but the four most substantial ones are:

• Lack of libraries: to really make your life easier, a good scripting language or framework needs to have lots of libraries to do what you need. Ruby does have lots of libraries. But when I started trying to learn it, I had two needs, and I could not find libraries for either of the two. My Rails-uber-guru colleagues couldn’t find them either. That doesn’t mean they don’t exist, but in Perl - you go to CPAN. In PHP, you go to the centrail PEAR repo. In Java, if it’s not there already, Apache already wrote it. In Ruby, it might be on Rubyforge. Or there might be thirty of them hosted on various people’s blogs - no telling which ones are bulletproof. This will get better with time.
• Lack of documentation: which is probably a legitimate complaint for anything FLOSS. And this goes hand-in-hand with the lack of libraries (or lack of a couple of de facto standard repo’s). With Java, you know the doc is good.
• Inability to leverage existing work: For new applications, Rails is fantastic. But because Rails runs on Ruby, there’s not (yet) a way for me to leverage my existing work in existing VM’s without turning my existing work into web services (shame on me for not doing it right the first time - but did you?)
• Key exposure: Part of the convention over configuration theme turns into key exposure. URL’s say things like http://server/blog/post/edit/832 - where 832 is the primary key field of the post I’m editing. Now, key exposure is not that big of a deal if 1) the key by itself has no meaning, which if you follow convention, it doesn’t, 2) there’s no SQL injection, which ActionRecord deals with nicely, and 3) you do permission checking for that object on every action - but that check is up to you.

That being said, Ruby on Rails is a really big and good step in the right direction. However, the first three items are killer for me - it doesn’t matter if I can “scaffold” a really complex schema in 8.3 seconds if I’m going to spend 8 weeks writing my own XSL translator or re-inventing the toaster oven.

In the next couple of posts, I’ll explain why I looked (back) into Groovy and why I’m (currently) geeking on Grails.

– Sylvan von Stuppe

Tags: Sylvan von Stuppe