Archive for the ‘Development’ Category

please hack my rails

October 17th, 2013 1 comment

Security is hard, it requires knowing your system is vulnerable, you should assume it is, but many Ruby on Rails developers seem to forget about it.

I’m writing this because a security vulnerability is promoted and it has to be stopped. The problem is adding bin, ./bin or $pwd/bin to $PATH. This is extended version of the problem with . in $PATH described here

When bin or it’s variation is in $PATH, attacker can place there executable that will be executed instead of system files and gives attacker possibility to run code on your system easily. This is described better here (for the . case):

So why would anyone advice us to jeopardize our system? The answer is bundle exec, it is so long to write and is required to run proper versions of gems placed in Gemfile. To avoid calling it the bundler gem introduces binstubs, many developers advised adding the bin variation to $PATH to simplify calling bin/binary to just binary.

I guess you are thinking now “how is it relevant, I do review my code before running any commands”, the question is “are you?”. There is a lot of tools and extensions to shell that run commands for you, the simplest would be using PS1 to display git status, something like \u@\h:\w $(git branch) > it will execute a git command when displaying the prompt. So when someone writes bin/git into the repository – it will be executed before you can review code after git pull. The prompt and pre command hooks are very popular now and give a lot of options for attackers when bin is in $PATH.

“What should I do then?”

First, you can stop being lazy and type bin/rake or bundle exec rake this way Bundler will be loaded without the possibility to add extra code to your $PATH.

Another solution that helps to fix this problem – I wrote a gem rubygems-bundler which automates calling bundle exec, it does check if the executed binary is part of Gemfile and automatically calls Bundler.setup when needed, this eliminates the need to use binstubs wrappers.

Day from opensource project maintainer: git commit –author

October 2nd, 2013 1 comment

Working as opensource project maintainer is a big task. I have been doing it for some time for the RVM project thanks to Engine Yard.


A big part of the maintenance is accepting others code for the project; it is very important to handle it well so the code author wants to get back to us and help again. As much as Ruby community is opensource oriented there are few things that can be improved. It happened a few times to me and other developers that the code was merged into projects without preserving authorship. This is a basic error made by maintainers, so I want to share some thoughts on how I try to avoid that problem when maintaining RVM. This problem mostly happens when the we want to change the commits, but is not limited to it and happens also without changes.

Easy way

When you do not care about number of commits you can merge the commit from Github or using hub and then add new commit on top updating it to proper state mentioning the ticket number in commit:

git commit -m "Formatting ..., update #2195"

For example see

Limit number of commits

The most basic method when you want to limit the number of commits is to apply changes from the committer and then commit it using the --author flag. I used this for – getting the proper result with involving author would require too much work as for small commit, so I did the required changes to the code (just changing order of paragraphs) and committed it using:

git commit -m "..., closes #2238" --author "Name <>"

It is important that the author matches exactly the original author name and email (from their commits) so it does not confuse others or tools used (like git annotate). Also make sure to mention the pull request (close #2238) so it is automatically closed and your commit is linked with it.

Work with the author

The slowest way is to actually talk to the author and explain to him/her what changes are required to make his/her commit accepted. For example, this happened in where most of the discussions happened on IRC or Skype sometimes in comments. This way the person contributing gets best experience and getting back to coding on your project is much easier for him/her.


Matz Is Nice And So We Are Nice

Most important for maintaining your project is treating other developers with respect, they are human beings, being impolite just builds a wall and ensures they will not get back to you or your project.

Other ways?

Obviously there have to be other ways to handle this, please comment below if you use another flow.

Categories: Development, Linux Tags: , ,

Review “Instant Sinatra Starter”

July 11th, 2013 Comments off

Two weeks ago I was asked to review book “Instant Sinatra Starter”, usually I get bored by technical books so I try to avoid them, this time I thought I can give it a try.

I need to point out on beginning that my review might be biased as I am maintainer of RVM, which got very low coverage in the book. It would cut few pages of unnecessary instructions that are system specific if RVM was used in the book.

Although I do not agree with few technical explanations and encouraged practices I found the book quite good and it guided me nice through Sinatra. The book goes into deep details about explaining every aspect of working with Sinatra, starting with very simple examples and extending progressively to the point where user can build full web app based on database. With more advanced topics the instructions get more tight missing some interesting details.

The book does not only focus on building the application but also on online hosting sources and application itself so it can be shared with others – the opensource model. Unfortunately the book in some categories goes into deep detail describing something like in case of templates, I think some diversity would help a bit, like beginning with basics of ERB templates and then going into detail of Slim templates, where now it starts and ends with Slim.

I would recommend this book for people wanting to start with ruby, it gives an easy start with great effects and multiple possibilities to play around and share results with friends. As good the book is for beginners I do not think more advanced users would consider it much useful, the book does end up to early not showing a bit more advanced topics like testing or modularization. Finally as tempting it is to use very small framework any app with few database tables, authentication and authorization will require reimplementing rails – so keep it small with Sinatra, for any bigger projects pick Rails.

Categories: Development, Review Tags: , ,


December 17th, 2012 14 comments

It’s a bit over a year as I work as RVM maintainer with over one and half year (19 months) of contributing to the project.

As I work on the project it was always improved, we spent a lot of time responding to user requests. At first I was helping Wayne E. Seguin the original author and later I took over as maintainer. We have been working hard in our free time to improve the first ruby environment switcher. We also had a lot of ideas how to make things better, but because it was our free time we were not always able to make all the ideas happen even implementing them would be as simple as just few lines change.

Today I want to share history of one of that ideas, automatic environment switching using a shell hook PROMPT_COMMAND =>, it is very easy idea allowing to execute piece of code every time user prompt is to be displayed. It was supposed to solve some limitations of overwriting builtin change directory command – cd, especially not rereading project file when it’s updated.

Before we were able to implement it a new project come to life – rbenv, it was also intended to do the environment switching but a lot simpler. Among of a lot of promotional keywords rbenv was accusing rvm of overwriting cd, which is considered harmful by rbenv author. To not feed the propaganda of a new tool rvm team has dropped all ideas related to accusations from rbenv. Among other interesting ideas rvm dropped also the idea of using PROMPT_COMMAND.

As time passes a lot of new tools was created to do the same thing – switching ruby environments. One of the tools is chruby, one of the most minimalistic implementations. I was helping from time to time the author with shell code, with understanding the problem of switching environment or just discussing various aspects of the tools we work on.

Of course there was also a need for automated switching of environment in chruby, the author started with cd function implementation as this is one of the easiest ways to archive this functionality. But then I have remembered of PROMPT_COMMAND and proposed use of it, which after quick test appeared to be better solution.

Seeing the idea working I have decided to implement it also for rvm, as initially expected this is a lot simpler code and solves some of the issues. We could have this code available for rvm users one year ago, possibly we could have a lot more of good solutions if the problems were discussed instead of throwing accusations as it was done by rbenv author.

So I wanted to sum the situation here, I wanted to disapprove the method of promoting opensource in cost of other opensource software without bringing discussion, without opening not a single ticket for the project. This are practices that you use fighting “corporate” world, as opensource authors we can choose to work together put aside all the politics, and do our work together for common benefit.

On the end I would thank postmodern the author of chruby for bringing up the discussion and working towards standardizing our software.

Categories: Development Tags: , ,

Testing shell scripts with Testing Framework

August 9th, 2012 2 comments

TF – Testing Framework

For some time I have been testing shell scripts using my own creation TF – Testing Framework.

I’m proud to present release 0.4.0 of it today. It includes:

  • 2-4x speed improvement depending on used Ruby interpreter,
  • add support for different shells via shebang
  • improved validation of environment variables, including array variables testing and testing environment variable type,
  • extended output matching allowing to separately match stdout and stderr,


Install using (ruby required):

gem install tf

Supported tests

The test can be negated by replacing = with !=:

  • #status=<number> – check if command returned given status (0 is success)
  • #match=/<regexp>/ – regexp match command output both stdout and stderr
  • #match[stdout|stderr]=/<regexp>/ – regexp match command either stdout or stderr
  • #env[<var_name>]=~/<regexp>/ – regexp match the given environment variable name
  • #env[<var_name>]?=[array|string|nil] – verify type of the given environment variable name
  • #env[<var_name><var_name>][]=<size> – verify size of the given environment variable name
  • #env[<var_name>][]=/<regexp>/ – regexp match all of elements of the given environment variable name
  • #env[<var_name>][<index>]=/<regexp>/ – regexp match given element of the given environment variable name

And here is very simple test:

true # status=0

false # status!=0

echo "Super" # match=~/^Super$/

rvm install 1.9.3 # match[stderr]!=/Error/; status=0

rvm alias create default 1.9.3 # status=0

TF is used for testing RVM, SM Framework and rubygems-bundler. Let me know if any other awesome projects use TF!

TF was earlier known as DTF – Deryl’s Testing Framework, but as original author Deryl wanted to go in a bit different direction (more validation related), I had to move code to this new repository and name.