A few days ago a large part of the Word Wide Web has been found vulnerable to the heartbleed bug in OpenSSL.
What is the vulnerability about?
The vulnerability is effectively a bug in all the versions of OpenSSL from Ver. 1.0.1 to 1.0.2. In reality a lot of web-sites are either using the older and still popular OpenSSL 0.9.8 or they have already upgraded to the latest patched version of OpenSSL and thus are NOT vulnerable to heartbleed.
Are you passwords safe ?
In a nutshell yes when they are posted or exchanged with a server that is not vulnerable to this attach:
GerritHub (gerrithub.io) has been vulnerable for only 5 days and then has been upgraded (see https://www.ssllabs.com/ssltest/analyze.html?d=gerrithub.io). However GerritHub DOES NOT exchange passwords over the Internet but rely on your existing GitHub session through OAuth Token authentication. This means that during the 5 days of vulnerability your account has NOT been at risk on GerritHub.
We do recommend then to change your GitHub password in order to be sure that any previous credentials potentially stolen would not impact the security of your account and repositories.
GerritHub relies on GitHub OAuth, so is GerritHub at risk as well ?
In real terms the answer is “potentially yes”: if a potential attacker had been stolen your GitHub password, he could have initiated a login on your behalf and then accessed GerritHub as well.
How can I strengthen my GitHub security ?
GitHub already support today the two-factor authentication (see https://help.github.com/articles/about-two-factor-authentication): if you have this extra security enabled, nobody other than you can ever access your account, even if they could have potentially stolen your password.
Can I have a GerritHub account secured independetly from GitHub ?
Not yet, however we are working on an advanced security option for the private GerritHub accounts. We will offer for a monthly extra fee:
Access to your GitHub private Teams and Repositories
Extra scripting functionality to hook Gerrit events on the server side
(commit validation, issue tracking association, …)
Integration with Atlassian Jira or BugZilla
Integration with BuildHive from CloudBees for Continuous Integration
Extra enterprise account protection for GerritHub.io accounts (additional password / X.509 Certificates)
Wow, that is amazing ! When can I get GerritHub private edition ?
We are currently in public beta stage, you can start using the implemented features for FREE during the trial by logging in to GerritHub using the URL:
The Gerrit User Summit 2014 is about to start in only 2 days: it is going to be a two days of exciting news and innovations on the world of Code Review. There are names from the largest industries in the world that have adopted the Code Review workflow in large enterprise environments: Google, SAP, SonyMobile, Ericsson, IBM, Garmin, HP, CollabNet, GerritForge, Codenvy, Eclipse Foundation and LibreOffice.
During all this week there is a special promotional discount on the Learning Gerrit Code Review book. Additionally, for the attendees of the conference, there will be a limited number of signed paperback copies available at the session “Gerrit or GitHub? Take both !”
In order to redeem the book promotion, scan the QR code and enter one of the following PROMO-CODEs:
Book PROMO-CODE: LGCRB20 eBook PROMO-CODE: LGCReB20
The Gerrit User Summit Agenda has been published yesterday and has a lot of very interesting talks and announcements:
Day 1 – Friday 21st of March
What’s new in Gerrit 2.8 (David Pursehouse – Gerrit maintainer – SonyMobile)
Scaling Gerrit at Ericsson (Patrick Renaud, Vladimir Cantiru, Hugo Ares – Ericsson)
Monitoring Gerrit (Doug Kelly – Garmin)
Browsing Repository Content with Gerrit’s REST API (Simon Kaegi – IBM)
Gerrit plugins made easy with Scripting (Luca Milanesio – GerritForge)
The Angular revolution in Gerrit! (Dariusz Luksza – CollabNet)
The day 1 would end with a very interesting Q&A with the Gerrit User Community about the features they would like to see coming up in the next forthcoming releases!
Continuous Development with Gerrit (Tyler Jewell & Luca Milanesio – Codenvy & GerritForge)
The day 2 will end with a meet-up with food and drinks sponsored and organised by Codenvy where the Gerrit Community can discuss and exchange their post-Summit impressions and ideas on the future of Code Review.
It is going to be again a huge leap forward for the Code Review community and the Git and Gerrit projects improvement !
On March 22nd, come see Codenvy CEO Tyler Jewell and Gerritforge CEO Luca Milanesio present at Google’s HQ in Mountain View, CA. They’ll cover Codenvy’s continuous delivery system for integrating code reviews, git, and SAAS developer environments in order to eliminate waste in the development workflow.
We are pleased to announce that we have successfully completed a new major hardware upgrade to the GerritHub.io platform.
What has been upgraded on GerritHub.io ?
There is a brand new production cluster which provides:
More memory (up to 32 GBytes per node)
More disk-space (up to 2TBytes per node)
More concurrency (up to 8 CPUs per node)
The new cluster is geolocated in Germany / Bayern and provides a much better and stable bandwith.
Do I need to change anything on my client ?
GerritHub.io is accessible from the old and the new IP addresses:
old IP address: 94.23.71.44
new IP address: 148.251.77.70
The GerritHub DNS is currently propagating the new IP to gerrithub.io and review.gerrithub.io hostnames: during the propagaton time (max 24h) both IPs will provide the same access to the Germany based production cluster.
What about my Git/SSH access ?
When using Git over SSH, the remote host SSH key is exchanged and associated to the resolved remote IP into ~/.ssh/known_hosts file in your local machine. This means that you have currently associated the GerritHub.io SSH public key to the 94.23.71.44 (old IP address).
When the DNS propagation will be completed, you will see a warning from your SSH client asking to verify that the new IP address is OK. In some cases you may be asked to verify and re-accept the SSH public key.
Example of the warning you would probably see on your Git client over SSH:
Warning: Permanently added the RSA host key for IP address '[148.251.77.70]:29418' to the list of known hosts.
Double-check that the IP address shown corresponds to the new GerritHub.io cluster (148.251.77.70). This warning will be displayed only once and then the new IP will be stored in your ~/.ssh/known_hosts file.
Support for GitHub private repositories is making substantial progress: we are proud to announce that the first milestone has been completed and is available for early access.
By using GerritHub on top of your existing GitHub private repositories, you can now define a safer set of commit policies and prevent Git forced pushes on a per-branch basis.
What is exactly GerritHub private repository support ?
With GitHub you can share code with other people and collaborate with the community of developers using public Git repositories on the Web. Your code is public by default and readable by anyone on the Web. This is the most typical case of using GitHub for the development of OpenSource projects.
However sometimes you want to restrict the access to your repository to a limited set of people or teams. Your code is not accessible to anonymous users but only the people you have selected from your GitHub Team security panel. This is typically the scenario of using GitHub for a private business or organisation.
How can GerritHub support private GitHub repositories ?
GerritHub is a public instance of Gerrit Code Review, which provides highly customisable sofisticated security. Whilst right now all GerritHub projects have shared a common public polity for all projects, you can customise your Gerrit project security and further restrict or extends the default permissions.
What are the benefits of GerritHub on private GitHub repositories ?
By using Gerrit Code Review on top of GitHub private repositories you can improve the security, collaboration and visibility of changes in your development team:
Provide a common dashboard with all pending changes on a per-project basis
Define validation rules for code to be merged, based on quality, scoring and build validation results
Notify people on what is happening on the project’s code
Define fine-grained permissions on a per-branch basis
Limit collateral damage by blocking accidental force-push on release branches
How can I get early access to GerritHub for private repositories ?
GerritHub for private repositories is FREE for the initial 30 days of early access: it would then be charged at 25% of your GitHub private subscription fee. This means that starting from the 3rd of April 2014 if you are paying $48/year on your GitHub personal plan, the GerritHub would cost only $12/year.
In order to switch to GerritHub private plan, you need to perform the following steps:
Accept the GitHub modify authorisation screen: you will be requested to grant full access to your GitHub personal profile and public/private repositories
Confirm your GitHub password
How can I import my private GitHub repositories ?
Once you logged in with a private scope in GerritHub, the full list of organisations and repositories are available on your import screen.
How can I customise my private repository security on GerritHub ?
You are free to use Gerrit Code Review security configuration screen on your imported private repositories, using the “Projects” top-menu, inserting your project name on the search box and select your project. The security configuration is available on the “Access” menu. Alternatively you can access the screen directly using the URL https://review.gerrithub.io/#/admin/projects/organisation/repository,access, where organisation is your username or organisation and repository is your GitHub repository name.
Where can I find more information Gerrit Code Review security and review rules ?
Alternatively if you would like a more gradual and descriptive step-by-step guide, the “Learning Gerrit Code Review” book at http://gerrithub.io/book available on Amazon provides an easy and accessible introduction to code review and security.
Comments, suggestions and hints are more than welcome !
What about Enterprise Support with guaranteed SLA on problems and incidents ?
GerritForge Enterprise Support on Gerrit Code Review covers the GerritHub cloud usage on private repositories as well. If you need guaranteed SLA you choose from one of the currently available support plans at http://gerritforge.com/support.
The interest in Gerrit Code Review is growing, possibly because of the increase of the Git adoption in the OpenSource and Enterprise and consequently the need of a set of best-practices on how to effectively manage a Git workflow when teams are growing: we do expect many new attendees this year !
Key information for the conference
Dates: Friday and Saturday March 21st-22nd, 2014
Location:GooglePlex – Mountain View, CA
Registration:Pre-registration is required, space is limited and registration is first-come, first serve. You can register NOW using the Application Form
Have something to share and present in a talk ?
Talks are open and you can submit your proposal using the Talk Proposal Form. We are expecting again the Gerrit plugins, scalability and the new UX to play an important role in the conference. Share your experience and how you managed to integrate the Code Review process in your Team !
Hope to see many of you at the Conference in March 2014.
When searching on Google with the keywords “Gerrit” and “GitHub” you find lots of different links with more questions than answers; see below a selection of the most interesting ones:
Google decided to use a different tool than GitHub and developed Gerrit Code Review for managing the community effort of developing the Android Operating System, mainly for two reasons:
GitHub pull requests model wouldn’t have worked for Android: forking the projects several thousands times would have been just unsustainable. Google recognized that early on and Gerrit was developed with the “not like GitHub pull request” requirement.
GitHub is not (and today has no plans to become) OpenSource
There are for sure additional reasons why even today and even if GitHub would decide to become OpenSource in the future a long set of features that GitHub would be needed in order to support a large-scale cooperative project !
What is Gerrit Code Review today ?
Today Gerrit is much more than the Android OS review tool ! There are around 80 contributors growing over time and from both large industries and OpenSource projects. SAP, Sony Mobile and Qualcomm IC are amongst the most active companies contributing to the tool whilst from the OpenSource community there are LibreOffice, Openstack and Wikimedia.
What is the right choice then ? red pill or blue pill ? Open or commercial ?
We thought about the problem very deeply at GerritForge.com as some of our customers decided to completely quit GitHub, mainly for security and confidentiality reasons but others moved into the opposite direction as well embracing GitHub:Enterprise.
In a nutshell the criteria that drove those customers into one (GitHub) or another direction (Gerrit Code Review) were based on the following aspects.
Security.
GitHub: history quite weak because of its architecture mainly based on Ruby (or let’s say a naive implementation based on Ruby, as the language itself is not so weak from a security perspective). Problem was solved but raised many concerns in the industry on how many more security problems are still to be found.
Gerrit: completely written in Java and with Security in mind. Large corporations such as SAP, Sony Mobile, Qualcomm and many other enterprises, organisations and non affiliated individuals/volunteers contributed to the review and development of the code-base. OpenSource and community code inspection has always the golden rule for very secure projects (e.g. OpenSSH and OpenSSL are widely reviewed and OpenSource) and code-obsucurity has always been a security anti-patterns.
High availability.
GitHub: it has been historically very reliable, especially at the beginning. When it started to become popular and saw its traffic to increase exponentially started to be rather unreliable because of several repeated DDoS attacks. GitHub:Enterprise is a proprietary-locked VM that can be installed on-premises but not on a private / public Cloud.
Gerrit: differently from GitHub, it is not a service and can be hosted either on your private / public Cloud or on-premises. Google has some instances in his own distributed cloud network around the world and managed with high availability in mind for Android OS development and other OpenSource projects (and for Gerrit self-hosting of course). Google’s deployment has not been impacted by DDoS attacks so far and its physical deployment is protected by the standard Google DataCenters network security. Other deployments are either private or distributed around different projects’ sites.
Usability.
GitHub: the key of the success of GitHub is its amazing user-experience and the ability to push the OpenSource development to a new level of social collaboration ! We all need to be grateful to GitHub for having made the OpenSource development ever more interesting and fun for the masses.
Gerrit: the user interface is functional but not “shiny” or “attractive” as a modern social collaboration platform should be. In a nutshell Gerrit does not want to be a developer’s social network but rather targets its specific objective of managing Code and Projects across large teams. This is the reason why large OpenSource communities such as the Eclipse foundation embraced Gerrit.
Scalability
GitHub: based on C-Git implementation (using the GitHub libgit2 library) that works very well with small repositories. However when the number of BLOBs and Packs increases the effort of counting them through the repository history grows linearly over time (*). With regards to the number of repositories, GitHub demonstrated to be capable of being very effective in distributing the data cross their nodes and sharing BLOBs for limiting the disk-space needed for forked repositories.
Gerrit: the R&D folks working at Google have invested a lot of time in optimising JGit for large repositories and a large number of users accessing them. The latest excellence of their performance improvements is represented by the JGit bitmap implementation (thanks to the fantastic work by Colby Ranger). Those optimisations however are not present in the C-Git code-base used by GitHub. With regards to the number of repositories the largest installation I have ever seen has less than 50K projects: it has never been used or tested with millions of repositories AFAIK.
(*) Note from Shawn Pearce on this topic: “Its just crazy slow per object, the C implementation discovers around 70k objects/second. 3M objects takes 42 seconds at best, the truth is the rate of new object discovery slows as it goes further back in history, which is why counting 3M objects takes modern machines minutes. GitHub has tried porting the bitmap code to C. Its running in some limited cases on their site, at one time https://github.com/torvalds/linux/ had it enabled. We haven’t seen updated patches for it, and it looks like its disabled again.”
Code Review
GitHub: uses the fork + pull model. In a nutshell every user always pushes to its own “forked version” of the repository and, once the changes are ready, request the source repository owner to pull its changes. Works very well for projects where there is a single approver of all the incoming changes and the GitHub user-interface is simply amazing in the way that changes are displayed and navigated in a unified-diffed view making the multiple commits review a simpler task.
Gerrit: being designed for projects with many contributors and committers, do not embrace at all the fork + pull model. It would have been simply unmanageable having hundreds of thousands of forked version of Android OS code-base ! The Gerrit workflow is mainly derived then from the Android OS contribution workflow: each contribution is defined as “Change”, has a unique ID (Change-ID) and is composed by a set of Patches (Patch-Set) of candidate changes. When the latest Patch-Set reaches the necessary score to be approved (Code-Review +2 and Validate +1 for the Android OS workflow) then it can be merged.
Why not using Gerrit and GitHub together ?
This is not a new idea as it has been proposed and successfully implemented by some popular OpenSource projects such as:
From the features and performance perspective the projects can benefit from the Gerrit JGit engine and associated Code Review capabilities. Gerrit Code Review model may seem less friendly than GitHub’s Pull Request but eventually generates a more readable and maintainable code-history, essential for long-term products in production.
From the point of view of accessibility and social community, the fact of using GitHub allows WikiMedia and Openstack to have an extended reach and at the same time even off-load all the clone traffic to GitHub nodes instead of their Gerrit servers !
Why GerritHub ? What is the value added by the platform ?
We thought about creating GerritHub about 2 years ago, when we first discussed with Kohsuke Kawaguchi, the adoption of Gerrit for the Jenkins Continuous Integration project. He liked Gerrit at first sight when he joined the Git Together in 2011 @Mountain View but at the same time he was concerned about the loss of reach and ease of use of GitHub.
The integration between the two tools was technical possible but challenging and needed some significant set of Gerrit skills to be implemented correctly, including the integration between the Pull Request model and the Gerrit Code Reviews.
GerritHub is the first Gerrit-powered platform that offers the best of Gerrit 2.8 (current master release) integrated with GitHub SSO (using OAuth 2.0) and replicated to GitHub repositories and Pull Requests. Differently from the WikiMedia and Openstack implementations, it is a self-service platform and anyone who has a GitHub account and repositories can self-register at GerritHub and use it for its own OpenSource projects !
Summary.
There is no winner in the battle between GitHub and Gerrit because they are simply different tools for different audiences. There are cases where the needs are mixed and both can provide a valid platform for the purpose of the projects.
Gerrit has been historically a niche tool, confined to the Android OS development: now things are different and major OpenSource projects adopted it as standard. However the need of a “public GitHub presence” was needed and has been implemented.
GerritHub gives you the choice of taking and using the best of both !
Learn more about Gerrit Code Review and GerritHub.
Many thanks to all the participants, locally in London and remotely from NY and CA in the USA: Dariusz, DaveB, DavidO, DavidP, Deniz, Edwin, Emanuele, Fredrik, Gustaf, Luca, Martin, Thomas, Shawn and Magnus !
It has been the very first Hackathon Event without Shawn (at least on-site with us in London … but for sure working hard night and day @Google on Gerrit !), we needed then to self-organise and be effective … the fact that we made it was another demonstration that the Gerrit Open Source Project is healthy and fully Open and Cooperative :-).
Shawn attended remotely anyway, for giving us initial guidance and then for the last day demos and for taking some key Gerrit Product decisions (i.e. moving from Maven to BUCK Build system) and the next steps on the 2013 Road Map.
A few days ago a large part of the Word Wide Web has been found vulnerable to the heartbleed bug in OpenSSL.
GerritForge Blog 