As always, I like building Emacs for my Mac from source. It lets me live on the cutting edge and have tigher control of the version I’m running. If building software from source isn’t your thing then skip the rest of this article and consider installing Emacs using Homebrew, MacPorts, or Fink

I’ve written about building Emacs in the past, but OS X Lion brings a few complexities to the process.

Before you begin you’ll need to have Xcode installed (free in the App Store).

In the past the best way to get the Emacs source was with CVS, but CVS is no longer included with Xcode. Fortunately, you can now use Git instead.

1
2

$ git clone git://git.savannah.gnu.org/emacs.git
$ cd emacs

At this point you have two choices, you can build the current stable version of Emacs, 23.3, which requires a patch to work with Lion. Or you can build the development version, 24.0, which has support for Lion, but requires a couple of extra tools.

First Emacs 23.3. The master branch of the repository is the 24.0 development branch. The stable 23.3 branch is called emacs-23. Check that out with:

1

$ git checkout emacs-23

Then use curl apply the patch found in this Gist:

1

$ curl https://raw.github.com/gist/1271239/adb92fb0d8d94c1e32f7d5ab1f33b438bb8ee379/nsterm.m-patch | patch -p1

Now Emacs 23.3 can be built and installed:

1
2

$ ./configure --with-ns
$ make install

Drag nextstep/Emacs.app to you Applications folder and you’re good to go. (The “install” step doen’t install anything, it builds the .app wrapper.)

If you want the future of Emacs today, you can build 24.0 instead. However, 24.0 requires newer versions of Autoconf and Automake than the ones shipped with Xcode 4.1.1. We’ll need to install those versions:

Autoconf:

1
2
3
4
5
6
7

$ cd /tmp
$ curl -O http://ftp.gnu.org/gnu/autoconf/autoconf-2.68.tar.gz
$ tar xf autoconf-2.68.tar.gz
$ cd autoconf-2.68
$ ./configure
$ make
$ sudo make install

Automake:

1
2
3
4
5
6
7

$ cd /tmp
$ curl -O http://ftp.gnu.org/gnu/automake/automake-1.11.tar.gz
$ tar xf automake-1.11.tar.gz
$ cd automake-1.11
$ ./configure
$ make
$ sudo make install

These will be installed in /usr/local/bin, so make sure you have that first in your PATH:

1

$ PATH=/usr/local/bin:$PATH

Now build Emacs as follows:

1
2
3
4
5

$ cd emacs
$ git checkout master
$ make configure
$ ./configure --with-ns
$ make install

It’s a bit of work, but anytime there is an update I can simply:

1
2

$ cd emacs
$ git pull

then re-config and rebuild to have it on my system.

After years of running on Wordpress, today I’m relaunching my blog using Octopress. Octopress is a blogging framework build on top of Jekyll which in turn is system designed for publishing static sites from source files, be they Markdown, HAML, SASS, etc. This style fits nicely in to my everyday workflow, so my hope is it will get me writing on a regular basis.

Wordpress is great if you want a WYSIWYG blog and I still recommend to my clients. But, if you spend your days in Emacs or Vim, running rake tasks and git commits, you might want to give Octopress a try.

Pow is a zero-config Rack server that makes developing Rack apps (include Rails apps) a snap on Mac OS X.

You install Pow:

1

curl get.pow.cx | sh

You create a symlink to your app:

1
2

cd ~/.pow
ln -s ~/dev/myapp

You point your browser to http://myapp.dev/ and there’s you app!   Awesome!

However, there is a downside:  Pow doesn’t play nicely with Apache (or any server listening on port 80). Life isn’t all greenfield, if in the course of the day you need to work on PHP or CGI legacy apps Pow is not so simple.   Pow creates a firewall rule that redirects port 80 to its port; to access Apache you need to either toggle the firewall rule on and off or move Apache to a different port all together. And now you’re running two web servers.  There has to be a better way.

The Win And there is, make your legacy app a Rack App.  Thanks to the rack-legacy gem, this is actually quite simple.

First, install the rack-legacy and rack-rewrite gems:

1

gem install rack-legacy rack-rewrite

(To sudo or not to sudo, that’s up to you).

Next,  in the top level of your legacy app create this config.ru file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

require 'rack'
require 'rack-legacy'
require 'rack-rewrite'

INDEXES = ['index.html','index.php', 'index.cgi']

use Rack::Rewrite do
  rewrite %r{(.*/$)}, lambda {|match, rack_env|
    INDEXES.each do |index|
      if File.exists?(File.join(Dir.getwd, rack_env['PATH_INFO'], index))
        return rack_env['PATH_INFO'] + index
      end
    end
    rack_env['PATH_INFO']
  }
end

use Rack::Legacy::Php, Dir.getwd
use Rack::Legacy::Cgi, Dir.getwd
run Rack::File.new Dir.getwd

The Details Rack::Legacy::Php runs any requested file with the extension .php. Rack::Legacy::Cgi runs any requested file that is set executable (which means you’ll need to make sure your .html files are not). Files that don’t end in .php and aren’t executable are served as static content by Rack::File.

The INDEXES array contains a list of files to check for if a directory is requested (just like Apache’s DirectoryIndex directive). You can change the order or use different names (default.htm anyone?).

The Catch rack-legacy uses the php-cgi command line program to run scripts and while PHP ships with current versions of OS X, php-cgi is not included. You’ll need to install PHP using MacPort/Homebrew/Fink/etc. That’s beyond the scope of this post but, if you’re doing this kind of development, it’s probably not beyond you.

The Caveat This is probably not a fast as running PHP using the Apache module and it’s certainly not as fast as something like FastCGI. If you are primarily developing legacy apps you probably should stick to Apache. However, if you mostly work with Rack apps and just occasionally need legacy support, this is a great way to go.

There’s plenty of documentation on how to deploy “Classic” style Sintra applications with Phusion Passenger, but it’s not immediately obviously how to deploy the new “Modular” style app (created with Sinatra::Base). Fortunately, it’s simple, the resulting class can be passed to “run” inside you “config.ru” file, something like:

1
2
3
4

require 'rubygems'
require File.join(File.dirname(__FILE__), 'lib/my_app')

run MyApp

That’s it.

Instructions you find for “Classic” Sintra apps have you setting “:env” to the ENV[‘RACK_ENV’] before running the app. As of Sintra 1.0 it’s “:environment” and it’s automatically set to ENV[‘RACK_ENV’] (or “:development” if RACK_ENV is not set). You’ll also see instructions for setting “:run” to false, this is not nessecary for “Modular” apps.

Instead of having a dedicated login page, some sites return a 403 Forbidden HTTP status code and include the login form in an HTML body of a custom 403 page. For example, Drupal admin pages work this way. While this may seem a little odd, it works; all modern browser will display the HTML and few, if any, will note the Forbidden status.

Mechanize on the other hand raise an exception when it receives a 403 status. Fortunately, it returns the page it received as part of that exception. Here’s how to handle it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

mechanize = Mechanize.new

begin
  login_page = mechanize.get("http://localhost/admin")
rescue Mechanize::ResponseCodeError => exception
  if exception.response_code == '403'
    login_page = exception.page
  else
    raise # Some other error, re-raise
  end
end
login = login_page.form_with(:action => '/login') do |f|
  f.field_with(:name => 'user').value = user
  f.field_with(:name => 'password').value = password
end.submit
raise 'Login Failed' if login.body !~ /Logged in!/

This code also works in the case where you don’t get a forbidden status, so it can be used generically.

For bonus points you can use the same code in a Cucumber step by changing:

1

login_page = mechanize.get("http://localhost/admin")

to:

1

login_page = webrat.adapter.mechanize.get(path_to('the admin page'))

(assuming you’ve set up “the admin page” in paths.rb).

I’ve given a number of examples of using Public-key cryptography in blog posts and in the Strongbox documentation, but I’ve always generated the RSA key pair using the openssl command line tool, i.e.

1
2
3
4
5
6
7
8
9

% openssl genrsa -des3 -out private.pem 2048
Generating RSA private key, 2048 bit long modulus
......+++
.+++
e is 65537 (0x10001)
Enter pass phrase for private.pem:
Verifying - Enter pass phrase for private.pem:
% openssl rsa -in private.pem -out public.pem -outform PEM -pubout
% cat private.pem public.pem > key_pair.pem

This is fine if you want to generate a key pair once, but what if you want to do it on the fly? The Ruby OpenSSL library has support for generating key pairs:

1
2

require 'openssl'
rsa_key = OpenSSL::PKey::RSA.new(2048)

2048 is the key size, and a good value to use for it.

What’s not obvious is how to encrypt the private key.   You don’t have to encrypt it, but, if you don’t, anyone who gets a hold of the key can decrypt your data.  Using an unencrypted private key gives you one layer of security (something you have - the key), encrypting it gives you an additional layer (something you know - the password).

To encrypt the private key you need a Cipher object:

1

cipher =  OpenSSL::Cipher::Cipher.new('des3')

Then, using the Cipher object, you convert the the key_pair to PEM format:

1
2
3

private_key = rsa_key.to_pem(cipher,'password')
public_key = rsa_key.public_key.to_pem
key_pair = private_key + public_key

The resulting PEM strings be saved and then later fed to OpenSSL::PKey::RSA.new() or used with Strongbox.

UPDATE: Emacs.app builds fine (and has for a while) as a 64 bit application.

As previous noted, when it comes to Emacs for the Mac, I’m a fan of Emacs.app. However, Emacs.app is not quite ready for Snow Leopard’s 64 bit support. You must compile it as a 32 bit executable.

1
2
3
4
5

cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co emacs
cd emacs
./configure --with-ns
make
make install  # This builds the .app wrapper, it does not install anything.

Then move nextstep/Emacs.app in to /Applications.

The developers have been actively working on Snow Leopard issues; hopefully 64 bit support is not far behind.

Scott Chacon, one of the guys behind GitHub, has released Pro Git, which, as the name suggests, is a new Git book.   He’s made it available under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license, which is to say it’s free.  It cover the basics you’d except, but really shines when it comes to advanced usages, customization, policy, hosting, internals, etc.  It’s the resource to reach for when it’s time to loose your amateur status.   And did I mention it’s free?

You can show your support by buying a print copy (the author’s link, not mine).

It also plays nicely with Fluid, using http://progit.org/book for the Fluid URL and perhaps picking up an image from Amazon for the icon.

I recently came across John Nunemaker’s take on using “unless” in Ruby and thought I’d share my two cents.

The key to making your code more readable with “unless” to is is to think semantics, not syntax. In spoken languages if there is more that one way to say something, there will be subtle differences in meaning. In English “unless” does not mean the same as “if not”, instead it indicates an exception or unlikely condition. For example, compare:

Unless it rains, we will go to the park.

to

If it’s not raining, we will go to the park.

The first sentence suggests that rain is possible, but not likely, the second that it is likely to be raining. To get the most out “unless” in your code, use it the same way.

John gives this as example of code that’s very readable with “unless”:

1

raise InvalidFormat unless AllowedFormats.include?(format)

Simple, elegant, and anyone reading it will understand that we expect the format to be allowed. In the unlikely case that the format falls outside of what we expect we raise an exception. Where as with “if”:

1

raise InvalidFormat if !AllowedFormats.include?(format)

is just a little bit ugly and says less about what is expected.

In his post, John argues against using “if” with “else” but I disagree. Again, I think in makes for more readable code when you are testing for an unexpected condition. Consider code that checks for an inactive user:

1
2
3
4
5

unless (@user.inactive?)
   #stuff
else
   redirect_to take_of_you_hoser_url
end

Reading the code, our expected course of action, doing stuff for the user, comes first, followed by the unlikely case that an inactive user is trying to do stuff. You could of course write:

1

if (@user.active?)

and there’s nothing wrong with that. However, I feel that using “unless” makes it clear what is expected.

In short, if you are using “unless” as a simple macro for “if !()”, then you shouldn’t be using it at all. However, “unless” is another tool which, when used with care, can make your code clearer.

Over a year ago I wrote the wildly popular Encrypting Lots of Sensitive Data with Ruby (on Rails). At the end I said:

Clearly, this screams for a plugin; watch this space.

Well, it took a while and it turned out to be a gem, but Strongbox has arrived.

First a recap:

You have a web application and you need to encrypt the data your receive from your users. The most common form of encryption is symmetric-key encryption, where one password is used for both encryption and decryption. This works very well, but it means that everyone who enters data needs to know the password and everyone who knows the password can decrypt the data.

Enter Public-key cryptography which used one password (key) to encrypt and a different key to decrypt. This solves the problem; make the encryption password, the public key, available to your application, and keep the decryption password, the private key, well, private. Users don’t need to know or care how, they fill out a form and the data gets encrypted. One small problem, size. The most you can practically encrypt using this method is 245 bytes. Good enough for the launch codes, but not so for driving directions to the buried treasure.

No problem, if we have larger data, we simply combine the two. We generate a random password and use it to symmetrically encrypt to data. We then use the public key to encrypt the random password. To get the data back, the private key is used to decrypt the random password which is in turn used to decrypt the original data.

Got it? Good. Strongbox takes the above three paragraphs and reduces them to this:

1
2
3
4
5
6
7
8
9

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :key_pair => 'path/to/keypair.pem'
end

>> @user = User.new
>> @user.secret = 'Ssssh'
>> @user.secret  # => "*encrypted*"
>> user.secret.decrypt ‘letmein’ # => "Ssssh"

OK, it’s sightly more complex. The column “secret” needs to exist in the database and be type “binary” (more on this in a bit). In additional, because we are using symmetric encryption (the default), we need two binary columns “secret_key” and “secret_iv” to store the generated symmetric key and Initialization vector (IV) (which you can think of as a second key (but it’s not) once they are encrypted with the public key.

If you are certain that the data you are encrypting won’t be larger than 245 bytes, you can use the following:

1
2
3
4
5
6

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :key_pair => 'path/to/keypair.pem',
                          :symmetric => :never
  validates_length_of :secret, :maximum=> 245
end

This skips the symmetric encryption, is faster, and you only need the binary “secret” column.

You’ll also need to generate a key pair. Be sure to choose a strong pass phrase, as this is the one that will decrypt everything (as always, I suggest using Diceware).

1
2
3
4
5
6
7

% openssl genrsa -des3 -out private.pem 2048
Generating RSA private key, 2048 bit long modulus
......+++
.+++
e is 65537 (0x10001)
Enter pass phrase for key_pair.pem:
Verifying - Enter pass phrase for key_pair.pem:

If you aren’t going to be decrypting data on a regular basis you might want to deploy just the public key. Extract it:

1
2
3
4

mv key_pair.pem private.pem
openssl rsa -in private.pem -out public.pem -outform PEM -pubout
Enter pass phrase for private.pem:
writing RSA key

And change your model:

1
2
3
4
5

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :public_key => 'path/to/public.pem'
                          :private_key => 'path/to/private.pem'
end

You could then have rake/Capistrano task to deploy and remove the private key as needed. Or you could limit it’s use to a separate, non-public, server.

As noted above you want your database column(s) to be binary. If your database does not have a binary type you can add the :base64 option:

1
2
3
4
5

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :key_pair => 'path/to/keypair.pem',
                          :base64 => :true
end

This will convert the binary data to text using Base64. You must, must make your column type “text”. Base64 increases the length of the data it encodes by approximately 137%. Type “string” is typically 256 bytes, 245 * 1.37 = 335.65 bytes. If you use a “string” column and encrypt anything greater than 186 bytes your data will be lost.

Finally, there are two addition options for tweaking the encryption settings that you are unlikely to need:

“:symmetric_cipher” lets you change the algorithm that’s used for symmetric encryption. The default is 256 bit Advanced Encryption Standard (AES) using Cipher Block Chaining (CBC) (‘aes-256-cbc’ in OpenSSL terms). AES has been approved by the NSA for top secret information, so it’s probably good enough, but Blowfish (‘bf-cbc’) is know to work as well. Other ciphers in CBC mode should also work, but have not been tested by me. (Note that all ciphers may not be supported by your version of OpenSSL, “openssl list-cipher-commands” will provide a list.)

“:padding” allows you to change the method used to pad data encrypted with the public key. Unless you are working with legacy data, you shouldn’t need to change this. The default is “RSA_PKCS1_PADDING”, see the code if you need other options.

Disclaimer

I am not a security expert. This software using an off the shelf encryption tool, namely OpenSSL, that has been well tested, but that is not a guarantee that this implementation doesn’t have weakness. Be sure you understand what Strongbox does, and review it for your application. A few things to keep in mind:

• Strongbox encrypts the data as it is saved, but no sooner. Be sure to use HTTPS for submitting the forms (and decrypting data!).
• If an attacker gains entry to your system the encryption should protect your data. However, they might be able to hack your code to intercept new data or, much worse, your private key password. Protect your server.
• When decrypting make sure your data isn’t cached.

And test, test, test. If there is a problem with how your data is encrypted, there is no getting it back.

One concern I have is garbage collection. If you decrypt something into a variable which then goes out of scope, how long does it hang around in memory? Can you force it out? I haven’t found much information on this; if there are any Ruby GC experts out there, share your knowledge!

I am always open to suggestions and improvement, but, to quote the License:

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

So there!

Finally, I’d like to give a shout-out to thoughtbot. While this software has existed for many years, the final form of the gem was greatly inspired by Paperclip. It’s a nice example of an approach to adding complex features to an ActiveRecord attribute and how to test them. In additional, the gem sat unpublished for nearly a year because it needed test coverage and my testing was week. Then I took thoughtbot’s Advanced Ruby on Rails class which really helped me get my head around testing and TDD, and got this moving again. If you know Rails, but need to improve your processes, I highly recommend this class.