Hey, there! Here at Plataformatec we like to do project rotations. It means that every three months or so, developers can swap projects. It has lots of benefits like working with different people, getting out of the comfort zone, sharing skills and knowledge, and the best one: a new developer can spot problems that people working for a longer time in the project may not see, since they are used to it.

But, it comes at a cost. Each project has its own setup process and may slow down the development. We’re using Boxen from GitHub to solve this problem. It works very well and allows us to have a project environment quickly set up.

But recently we have run into a problem that Boxen couldn’t solve. We had a project which has multiple repositories and some of them are too large. It would take some time just to git clone their > 3GB size repos.

Our first thought was creating a tar file with gzip or lzma compression. The problem with it would be when extracting, since file ownership and permissions on it could be a problem just like symlinks. So, the solution was to git clone the smallest repos and git bundle the larger ones. Git bundle is shipped with git, but only a few people know about.

The workflow we have is simple. Someone with the repo already cloned and updated to the origin, type the following command:

$ git bundle create .bundle master

It will create a file called .bundle with a compressed version of the repository containing the master history. So, this file can be shared via a flash drive, AirDrop or netcat (using the internal network) among developers, and it will take way less time than cloning it.

Now that you have the file in hands, it requires two steps to work properly. The first one is extracting the bundle into a cloned repository. This can be achieved by:

$ git clone .bundle -b master

In case you want to clone into a different path other than in the current working directory, you can pass the path after the -b master option. As you can see, the repo is cloned from a bundle file just like it could be an URL or some bare git repo in your machine. That said, just take a look at your origin remote.

$ git remote show origin

* remote origin
Fetch URL: /path/to/.bundle
Push URL: /path/to/.bundle

It is pointing to the bundle filename, so every time you fetch or push, it will try to do so in this bundle file. To fix that, we go to the second step which is setting the proper remote URL.

$ git remote set-url origin

That’s it. You’re ready to go. If you have multiple repositories to share, you can create a script to automate the cloning and the url setting for the origin. You can share all the repos with this script, for faster and easier setups.


The Ruby language repository size is about 200MB. It is not big enough to require a bundle, but just as an example I guess it would be a nice fit.

The first step is cloning the repo:

$ time git clone https://github.com/ruby/ruby.git
Cloning into 'ruby'...
remote: Finding bitmap roots...
remote: Reusing existing pack: 269821, done.
remote: Counting objects: 2813, done.
remote: Compressing objects: 100% (1403/1403), done.
remote: Total 272634 (delta 1707), reused 2213 (delta 1390)
Receiving objects: 100% (272634/272634), 136.77 MiB | 1.20 MiB/s, done.
Resolving deltas: 100% (210263/210263), done.
Checking connectivity... done
Checking out files: 100% (4187/4187), done.

real 4m51.501s
user 1m38.837s
sys 0m18.808s

As you can see, it takes almost five minutes to clone the full repository – the time may vary depending on your bandwidth. So, now we’re gonna create a bundle file and then clone a new repo from it:

$ cd ruby/
# Just a reminder, the main branch of ruby repo is not master, it's trunk.
$ git bundle create /tmp/ruby.bundle trunk

Now that we’ve created a bundle file and placed it in /tmp, we just need to clone it:

$ cd /tmp/
$ time git clone /tmp/ruby.bundle -b trunk ruby
Cloning into 'ruby'...
Receiving objects: 100% (206590/206590), 84.16 MiB | 22.43 MiB/s, done.
Resolving deltas: 100% (158583/158583), done.
Checking connectivity... done
Checking out files: 100% (4187/4187), done.

real 0m46.490s
user 1m9.339s
sys 0m10.021s

Cloning from a bundle file was much faster and has not taken a minute. Now, in order to pull and fetch changes, you need to set the remote URL:

$ git remote set-url origin https://github.com/ruby/ruby.git

Enjoyed this post? Was it as useful for you as for us? Tell us your stories on the comments below! See you!

There is a XSS vulnerability on Simple Form’s label, hint and error options.

Versions affected: >= 1.1.1
Not affected: < 1.1.1
Fixed versions: 3.0.1, 2.1.1


When Simple Form creates a label, hint or error message it marks the text as being HTML safe, even though it may contain HTML tags. In applications where the text of these helpers can be provided by the users, malicious values can be provided and Simple Form will mark it as safe.


The 3.0.1 and 2.1.1 releases are available at the normal locations.


If you are unable to upgrade, you can change your code to escape the input before sending to Simple Form

f.input :name, label: html_escape(params[:label])


To aid users who aren’t able to upgrade immediately we have provided patches. They are in git-am format and consist of a single changeset.


Thank you to Paul McMahon from Doorkeeper for reporting the issue and working with us in a fix.

It has been reported that malicious users can do e-mail enumeration on sign in via timing attacks despite paranoid mode being enabled.

Whenever you try to reset your password or confirm your account, Devise gives you precise information on how to proceed, if the e-mail given is valid, if the token has not expired and so on. This means that, by trying any given e-mail, a third-party person can know if a particular e-mail is registered in that website or not.

While this is not a problem for many applications, some applications would like to keep their user information completely private, even if it means loss of usability on features like account confirmation. For such use cases, Devise supports something called paranoid mode, which has been reported to still be vulnerable to enumeration on sign in.


Only applications using Devise paranoid mode need to update. New releases have been made for Devise branches 3.2 (3.2.1), 3.1 (3.1.2), 3.0 (3.0.4) and 2.2 (2.2.8).

Users running on those branches and cannot upgrade immediately can fix this issue by applying this patch. Users running on older versions are recommended to upgrade to a supported branch immediately.


We want to thank Tim Goddard, from YouDo Ltd for reporting the issue and working with us on a fix.

No último dia 19 de outubro de 2013, aconteceu em Porto Alegre, nas dependências da PUC-RS, o RS on Rails. Eu, João Britto e Lucas Mazza participamos do evento que conseguiu abranger palestras que falavam sobre a cultura e os hábitos do programador, importantes para o desenvolvimento pessoal; as de cunho técnico, compostas com bastante código, para desenvolvimento técnico; e também cases reais, que mostram como o mundo realmente é fora dos livros.

Alguns participantes do RS on Rails 2013. Foto por Gabriel Sobrinho

Gostaríamos de agradecer o convite e o cuidado da organização, que se preocupou desde a localização do hotel até em apresentar a cidade e seus costumes. Foi muito bom continuar o networking na Redenção e tomar um chimarrão com o pessoal após o evento.

Abaixo, seguem os talks que nós apresentamos no evento. Sinta-se à vontade para dar feedback nos comentários abaixo!

Contribuindo com Open Source: a teoria na prática – por Lucas Mazza

A palestra fala sobre como a cultura do Open Source influencia o nosso dia-a-dia,
pois Open Source não se resume a “programar de graça”, e sim, a um espírito maior de colaboratividade.

Um time, vários projetos – por Gustavo Dutra

Eu falei sobre colaboratividade entre todos da empresa. “Um time, vários projetos” trás um pouco da realidade da Plataformatec e várias dicas de como conseguir trazer o sentimento de um único time entre todos da empresa.

Ruby além dos trilhos – por João Britto

Já o João Britto mostrou alternativas ao “feijão com arroz” do Rails e do Ruby. Na “Ruby além dos trilhos”, ele apresentou vários questionamentos, todos regados de muito código para exemplificar as ideias.

We are glad to announce that Devise 3.1.0.rc is out. On this version, we have focused on some security enhancements regarding our defaults and the deprecation of TokenAuthenticatable. This blog post explains the rationale behind those changes and how to upgrade.

Devise 3.1.0.rc runs on both Rails 3.2 and Rails 4.0. There is a TL;DR for upgrading at the end of this post.

Note: We have yanked 3.1.0.rc and released to 3.1.0.rc2 which fixes some regressions. Thanks everyone for trying out the release candidates!

Do not sign the user in after confirmation

In previous Devise versions, the user was automatically signed in after confirmation. This meant that anyone that could access the confirmation e-mail could sign into someone’s account by simply clicking the link.

Automatically signing the user in could also be harmful in the e-mail reconfirmation workflow. Imagine that a user decides to change his e-mail address and, while doing so, he makes a typo on the new e-mail address. An e-mail will be sent to another address which, with the token in hands, would be able to sign in into that account.

If the user corrects the e-mail straight away, no harm will be done. But if not, someone else could sign into that account and the user would not know that it happened.

For this reason, Devise 3.1 no longer signs the user automatically in after confirmation. You can temporarily bring the old behavior back after upgrading by setting the following in your config/initializers/devise.rb:

config.allow_insecure_sign_in_after_confirmation = true

This option will be available only temporarily to aid migration.

Thanks to Andri Möll for reporting this issue.

Do not confirm account after password reset

In previous Devise versions, resetting the password automatically confirmed user accounts. This worked fine in previous Devise versions which confirmed the e-mail just on sign up, so the e-mail both confirmation and password reset tokens would be sent to were guaranteed to be the same. With the addition of reconfirmable, this setup change and Devise will no longer confirm the account after password reset.

Thanks to Andri Möll for reporting this issue and working with us on a fix.

CSRF on sign in

Devise’s sign in page was vulnerable to CSRF attacks when used with the rememberable feature. Note that the CSRF vulnerability is restricted only to the sign in page, allowing an attacker to sign the user in an account controlled by the attacker. This vulnerability does not allow the attacker to access or change a user account in any way.

This issue is fixed on Devise 3.1.0 as well as 3.0.2 and 2.2.6. Users on previous Devise versions can patch their application by simply defining the following in their ApplicationController:

def handle_unverified_request
  Devise.mappings.each_key do |key|
    cookies.delete "remember_#{key}_token"

Thanks to Kevin Dew for reporting this issue and working with us on a fix.

Store digested tokens in the database

In previous versions, Devise stored the tokens for confirmation, reset password and unlock directly in the database. This meant that somebody with read access to the database could use such tokens to sign in as someone else by, for example, resetting their password.

In Devise 3.1, we store an encrypted token in the database and the actual token is sent only via e-mail to the user. This means that:

  • Devise now requires a config.secret_key configuration. As soon as you boot your application under Devise 3.1, you will get an error with information about how to proceed;
  • Every time the user asks a token to be resent, a new token will be generated;
  • The Devise mailer now receives one extra token argument on each method. If you have customized the Devise mailer, you will have to update it. All mailers views also need to be updated to use @token, as shown here, instead of getting the token directly from the resource;
  • Any previously stored token in the database will no longer work unless you set config.allow_insecure_token_lookup = true in your Devise initializer. We recomend users upgrading to set this option on production only for a couple days, allowing users that just requested a token to get their job done.

Thanks to Stephen Touset for reporting this issue and working with us on a solution.

Token Authenticatable

Jay Feldblum also wrote to us to let us know that our tokens lookup are also vulnerable to timing attacks. Although we haven’t heard of any exploit via timing attacks on database tokens, there is a lot of research happening in this area and some attacks have been successful over the local network. For this reason, we have decided to protect applications using Devise from now on.

By digesting the confirmation, reset password and unlock tokens, as described in the previous section, we automatically protected those tokens from timing attacks.

However, we cannot digest the authentication token provided by TokenAuthenticatable, as they are often part of APIs where the token is used many times. Since the usage of the authenticatable token can vary considerably in between applications, each requiring different safety guarantees, we have decided to remove TokenAuthenticatable from Devise, allowing users to pick the best option. This gist describes two of the available solutions.

Thanks to Jay Feldblum for reporting this issue and working with us on a solution.

TL;DR for upgrading

As soon as you update Devise, you will get a warning asking you to set your config.secret_key. By upgrading Devise, your previous confirmation, reset and unlock tokens in the database will no longer work unless you set the following option to true in your Devise initializer:

config.allow_insecure_token_lookup = true

It is recommended to leave this option on just for a couple days, just to allow recently generated tokens by your application to be consumed by users. TokenAuthenticable has not been affected by those changes, however it has been deprecated and you will have to move to your own token authentication mechanisms.

Furthermore, the Devise mailer now receives an extra token argument on each method. If you have customized the Devise mailer, you will have to update it. All mailers views also need to be updated to use @token, as shown here, instead of getting the token directly from the resource.

With those changes, we hope to provide an even more secure authentication solution for Rails developers, while maintaining the flexibility expected from Devise.

One more thing, we’re writing a free ebook about Devise!

If you want to know more about Devise, we’re writing a free ebook about it.
Fill in the form below so that we can send you updates with new chapters and beta releases.

July and August of 2013 will be a mark in the Plataformatec history as the time when we moved out from our green house in the Vila Madalena neighbourhood to a brand new office in the region of the Paulista Avenue.

The brand new Plataformatec HQ 2.0

The brand new Plataformatec HQ 2.0

Our company has grown a lot in this year (we are about to pass the number of 20 developers in our team, can you believe it?) and our office wasn’t enough to accommodate the entire company anymore. So we have been out in the city looking for a new house for us. We took our time to pick a new place for us to call of ‘Headquarters’, that wasn’t an easy task to do. We chose a beautiful and charming antique house, but since it is almost 100 years old, it needed to go through a lot of repairs and improvements to accommodate the Plataformatec team.

So, while we are in between places, some of our teams are working remotely across different places in the city as we wait for our new office to be ready. But thanks to our heavy usage of asynchronous communication channels our productivity looks the same as before. We use tools like Basecamp, GitHub, Skype and Campfire to get our things done and talk about our projects – from like code reviews to scope related discussions and everything else – without getting in the way of anyone who might be busy with something else, so when we end up working apart it isn’t such a big deal since we are used to communicate and work in some sort of remote way.

But while some developers would jump out of happiness for the chance of working from homes, I miss that good old office that I used to commute to everyday, because I don’t go to work to work.

In all these months at Plataformatec the office has proven to be much more than a place to write code and do our work. It became a place to share our stories, to improve our craft, to build our projects together and to have fun with our friends. So working from home without the whole “HQ Experience” isn’t quite the same thing for me and some of the others members of our team.

Our first tour in the new Headquarters.

Our first tour in the new Headquarters

All of the effort we have put into developing and maintaining our culture and values has reflected in a work environment completely different from any average consulting office, and as the company grows and we improve our values we hold the responsibility to keep improving our HQ for everyone who is or will be part of the company.

We couldn’t be more thrilled about this. I would like to thank everyone who have been cheering and following our work, and we would love to share our excitement with this new chapter in the history of Plataformatec. Be sure that we are going to post and tweet a truckload of pictures and videos as we move in to our new HQ. Let these new chapter be as great as our history have been.