Be sure to take a closer look at the Gitlab source code. The last time I did, they still were vulnerable to exactly the same attacks that were also demonstrated to work on Github some time ago.
I'm pretty sure it should have it's attributes protected.
Also, prepare to have to work with pretty confusing code. I don't want to belittle the work of the Gitlab authors and contributors, but the whole codebase is ignoring many Ruby, Rails, Webdevelopment and general programming best practices.
A short list of problems, at least in my eyes, and in no specific order:
* Obtrusive JavaScript inside the erb templates, inline style definitions
* Non-semantic css class names.
* Highly confusing controller code (filters are used to set all kinds of instance variables, which makes it very hard to easily understand where the variable is coming from and what it's value is).
* "Roles": Code that has been extracted into seperate modules, but for no real reason. E.g. the SshKey module is only included into the Key class, and is highly coupled with it.
* Totally brittle test suite.
Thank you for the heads up. I must say I've seen worse projects but I won't argue with the points you raised.
In general I think that compared to the alternatives Gitlab is the least complex to understand and install. Of course that doesn't mean it is perfect or easy. These two lines took us a few hours: https://github.com/gitlabhq/gitlabhq/pull/1263
I think the Gitlab author already did an awesome job and luckily there are many people sending in pull request, already more than 1200!
We try contribute our part. With the growth of Gitlab.io our contributions should grow as well.
Hah! Your pull request actually introduces subtle bugs into the diff view. I had already submitted _exactly_ the same change some months ago, and after having it enabled for some time in our gitlab installation at work, I ran into some issues.
I can't remember the exact preconditions, but there were cases where this change would start showing changes that were not even part of the merge request at all, which was extremely confusing.
In the end, I went ahead and did some more low-level changes to gitlab, so it would not only save the branch for a merge request, but it would save the actual commit shas of the source revision. That was much more accurate and reflects the way pull requests work on Github.
Thank you for the hint, I will certainly have a look at the Gitlab source to check if the countermeasures are in place. http://guides.rubyonrails.org/security.html#countermeasures