PresidentBeef.com

Manually Vendoring Rails 1.2.3...

Mon, 6 Jun 2011 18:58:00 CDT

A few days ago, my shared hosting provider ( Site5 – I do recommend them ) moved my account to a new server. Understandably, this new server had new versions of Ruby and Ruby on Rails. Sadly, my site uses Ozimodo, a (ancient) tumblelog application built for Rails 1.2.3, and I had been unknowingly depending on the global version of Rails. Naturally, my site went kerplumpf once it was moved to the new server. After fighting with it for some time, I foolishly thought that I was able to just switch directly to Rails 2.3.8. This actually seemed to work for a moment (the main page displayed!) but everything else was still broken. I attempted to vendor Rails (that is, have a copy of the right version of Rails inside my rails app in vendor/rails) but I kept getting errors like this:


$ rake rails:freeze:gems
(in /home/fair/pkgs/ozimodo)
rake aborted!
undefined method `manage_gems' for Gem:Module

After fussing about for a long while, trying to use different versions of RubyGems and all sorts of silly ideas, I went ahead and found the rails:freeze:gems task (it’s in framework.rake) and manually completed what it is supposed to do automatically: # Install Rails 1.2.3 if you have not already # Create vendor/rails # gem unpack actionmailer (1.3.3), actionpack (1.13.3), actionwebservice (1.2.3), activerecord (1.15.3), activesupport (1.4.2), and rails (1.2.3) into `vendor/rails` # Rename each directory without the version name (e.g., “actionmailer-1.3.3” -> “actionmailer”) except rails. # Rename rails-1.2.3 to railties You may also need to set GEM_PATH to /home/yourname/ruby/gems, I can’t remember if that was necessary or not. This was the process, as well as I can remember, which got this site back up and running again.

Pushing Brakeman

Mon, 23 May 2011 22:17:00 CDT

I have been trying to do a bit more advertising of Brakeman lately. I have two reasons for doing so: firstly, I think it’s a really useful tool and will make the world a safer place. Secondly, I keep hoping someone else will find bugs in it for me. One of my design decisions for Brakeman is that it should never crash and should always output some kind of report. I don’t always meet this goal, so I am very interested in any cases where a Rails app will actually make Brakeman fall on its face. Lately, I have (finally) been putting together a test suite. I’m already finding issues with features I thought were working. Hopefully it will help me avoid embarrassing regressions in the future, too. If you are in the Los Angeles area, I will be presenting on using Brakeman with Jenkins at the LA OWASP on Wednesday the 25th. Then, next month, I have a similar but unconfirmed talk at LA Ruby. The difference between the two is that I will talk more about Ruby and Rails at the OWASP meeting. At least, I think I will. This blog post is part of my avoiding actually making the slides. Oh, what is Brakeman? It is a static analysis tool for finding security vulnerabilities in Ruby on Rails applications. It does a pretty good job, most of the time.

Brakeman Updates

Sat, 14 May 2011 19:52:00 CDT

Brakeman is a static analysis tool for Ruby on Rails that looks for security vulnerabilities. The cool thing about Brakeman is that pretty much all you need is your code: there is no need to set up a database or a web server or anything of that sort. The code doesn’t even need to be working completely. Brakeman has been working pretty well for Rails 2.x code, but no one really cares about that any more. Rails 3.x is the new hotness. So I have been working on getting Brakeman to work with Rails 3. The latest gems will attempt to detect Rails 3 automatically (otherwise, there is the `-3` options). There are some known issues to be fixed, but I think it’s past the “catastrophic crash and burn” stage. I would encourage people to try it out. Also, I have released a Jenkins/Hudson plugin for Brakeman With a minimal amount of setup, you can have Jenkins run Brakeman automatically. It uses another nice plugin to make pretty graphs and tracks the vulnerabilities found so you can see right away when things go wrong.

Life at the End of April

Sun, 24 Apr 2011 23:16:00 CDT

I have started to feel guilty about neglecting this site, so here is a recap of my life right now: School drags on, but if all goes well I will at least advance to candidacy at the end of this week. I’m pretty nervous about it, though. Work is weird because I work at AT&T Interactive but I work for AT&T, yet I do work for AT&T Interactive. Even more confusingly, the sign outside the building still says YellowPages.com. My hobbies now include archery, which is thoroughly addictive, so you will find me on the range most Saturdays and Sundays and even on some weekday evenings. In my more personal life, I will be getting married in approximately five months. I’m pretty happy about that. And that’s a pretty good summary of where I am right now. A good portion of my activities can been seen on GitHub if you like more frequent updates.

Writing Code for You

Sun, 13 Mar 2011 00:49:00 CST

From Tom Sawyer: bq. ...Work consists of whatever a body is obliged to do, and that Play consists of whatever a body is not obliged to do. It is common in the open source world to hear that someone wrote some software to “scratch their own itch.” The implication is usually that they wrote the code to meet some need (or annoyance?) they had, and it may, by mere coincidence, be useful to others as well. Sometimes this phrase also used to excuse the software or lack of support for it. It may also be used to provide guidance for those wanting to write software: do something useful for yourself. I think there is a considerable amount of wisdom in this approach. Nothing motivates a person like a genuine interest in a project. The best learning (in my non-scientific opinion) occurs when a person is driven by their own interest. Outside pressures can only do so much. I often see Project Euler or some kind of “programming koans” offered up as suggestions to improve one’s programming skills. I find these to be unhelpful for me, as I cannot make myself be interested in them. In fact, I should not need to force myself to be interested at all: that pushes the activity into the “work” category and the exercise has already failed. For programmers, we should be writing code which we want to write, solving problems we want to solve, and producing something we want to make. Along the way, we may accidentally learn all kinds of new things, but only because those things are on the path of building our project. It is not about making something useful, or good, or desirable. It is about the joy of creation. That does not mean it is all bunnies and sunshine, though. I have hit my head against the wall more times over software I was writing for fun than any homework problem. Why? Because they were problems I intensely desired to overcome – for myself. The point, in case I have not beaten it to death already, is that you should write code for you. It doesn’t matter if it isn’t perfect or won’t compile on anyone else’s machine. It doesn’t matter if twenty other programs exist that do the same thing. All that matters is that you write it. Learning is merely a side effect.

An actually decent Ruby chat se...

Wed, 5 Jan 2011 23:45:00 CST

There are a few examples around the ‘net of chat servers in Ruby, which seem to me to be unnecessarily complex or else too simplistic. This is a simple version, too, as it is intended to meet the requirements over at RosettaCode. However, I think I’ve covered most of the common failure points.
h2. Caution If connecting with a client like PuTTY, use “raw” mode to avoid telnet negotiation.

Brakeman: A Vulnerability Scann...

Tue, 7 Sep 2010 17:36:00 CDT

I spent this summer doing an internship at ATTi, during which I developed a static analysis tool called brakeman for finding security vulnerabilities in Ruby on Rails applications. h3. What it is Brakeman uses Ryan Davis’ Ruby Parser to parse the code of your RoR application, mangles it a bit, extracts some information, and then runs various checks on the result. It then uses Ruport to generate a report. The HTML reports look like this. Because brakeman analyzes the source code, there is no need to wait until the application is deployed to start testing it. Brakeman can be run at any point in the development process. h3. What it can do Right now, brakeman can find these kinds of problems: * Cross site scripting vulnerabilities * SQL injection * Command injection * Unsafe redirects * Unrestricted mass assignments * Insufficient validation regexes * Default routes * Dynamic render paths It can also check configuration settings, such as cross site request forgery protection and session secret length. Unfortunately, it is not (yet?) compatible with Rails 3.0. Hopefully it will still be of use to a lot of people, though. h3. Installation Brakeman can be installed as a gem (and, in fact, that is how I would recommend doing it): gem install brakeman (may require sudo). h3. Documentation brakeman -h provides information on the options available. I’ve also been working on fleshing out the wiki with more detailed info. h3. Problems? I really want this to be a useful tool, so if it does not work for you or there are any problems, please file an issue or even just leave a comment on this post. I’ll do my best to get everything fixed up.

Spellcheck/Suggest for RubyGems...

Fri, 14 May 2010 16:31:00 CDT

As a result of a Ruby bounty, I wrote a patch for RubyGems which provides suggestions when you try to install a gem and you get the name a little wrong. You can see all the details here. Now that RubyGems 1.3.7 is out, I’m going to go ahead and provide a patched version for those who frequently forget, mistype, or misspell gem names (this includes myself). Download .tar.gz Download .zip After decompressing, I recommend installing it with ruby setup.rb --no-rdoc --no-ri (and probably sudo). Here are some examples of what this adds to your RubyGems experience:

$ gem install Blah
ERROR:  Could not find a valid gem 'Blah' (>= 0) in any repository
        Possible alternatives: blahblahblah

$ gem install Nkojiri
ERROR:  Could not find a valid gem 'Nkojiri' (>= 0) in any repository
        Possible alternatives: nokogiri

$ gem install blue
ERROR:  Could not find a valid gem 'blue' (>= 0) in any repository
        Possible alternatives: bluecloth, BlueCloth, bluefeather,
         blue_light_special, blue_light_special_heroku_fork, glue, bluepill,
         blueprintr, blueprints, bluepay, ...

$ gem install sinatar-capcha
ERROR:  Could not find a valid gem 'sinatar-capcha' (>= 0) in any repository
        Possible alternatives: sinatra-captcha, sinatra-cache, sinatra-cas, sinatra-auth,
         sinatra, sinatra-any, sinatra_app_gen, sinatra-flash, sinatra-dm, sinatra-dm-auth,
         sinatra-doc, sinatra-erb, sinatra-compass, ...

git revert a single file

Fri, 16 Apr 2010 21:37:00 CDT

git checkout <filename> I’m putting that first for people who don’t need a story. To be honest, I cannot believe it took me so long to find this out. It seems like such a simple thing. You have a git repo. You’ve made changes to a few different files, when you realize you just want to start over on one of them. You could do git reset --hard, but then you lose all of your changes. You could commit all the other changed files, then do a git reset, but what if you aren’t done with editing the other files? In Subversion you can svn revert a single file. Since that is what I fairly frequently wish to do, I searched high and low for a way to do this seemingly simple operation. Then, one day glorious day, I found it. And now so have you.

Carrot Carnage

Sun, 31 Jan 2010 04:43:00 CST

Yum.