What's New in Review Board

Earlier this week, we released RBTools 0.7.8 with some great improvements to the macOS and Windows installers. Unfortunately, the macOS installer build was built in the wrong environment, leading to incorrect paths and a failing rbt.

The new 0.7.9 release contains a fix to the installer generation process to prevent this from happening again. We've rebuilt and carefully checked the new installer build, and it should be good to go.

If you tried upgrading to the 0.7.8 installer using macOS and had trouble, please give 0.7.9 a try. You can get it from the downloads page. If you installed on Linux or Windows, you don't need to worry about this release.

Note that you might also find a /Users/chipx86 directory on your filesystem from the bad installer. This is an artifact of the broken build. You can safely remove it.

See the release notes for more details.

We have a new RBTools release for you today, with some major improvements to the macOS/Windows installers and a few bug fixes and feature improvements.

Let's break it down.

A non-broken macOS installer

We fixed a problem that many of you have reported to us, where one of the dependencies (tqdm) could show up missing, breaking RBTools. We've fixed this and made sure it can't happen again.

We've also improved the installer for modern versions of macOS. For compatibility reasons, we install RBTools for both Python 2.6 and 2.7, and the way we installed it used to favor Python 2.6 for the actual rbt binary. Now, the preferred Python version for your system is now used, helping with various compatibility problems that have been reported.

A more modern Python on Windows

We've updated Python on our Windows RBTools installer. We now ship Python 2.7.13, which has a number of improvements over the older 2.7.6 release. If you've had issues with SSL certificate verification before, this should help address those problems.

A few other improvements

Such as:

• rbt setup-repo now sets the REPOSITORY_TYPE setting for your repository in .reviewboardrc, speeding up posting changes for review.
• rbt patch --print can now be run outside of a source tree.
• Some various crashes involving Unicode characters on the command line and in Team Foundation Server diffs.

For the complete list, see the release notes.

To upgrade RBTools, visit the downloads page.

We've just put out an all-new release of RBTools. Version 0.7.7 features compatibility fixes for various types of repositories, better support for TFS, and some new features to help with common usage and automation.

You can see the release notes for the full list of changes. We'll go over the highlights here.

Compatibility/bug fixes

In this release, we've aimed to fix a handful of compatibility problems that have been reported to us. Thanks to all the contributors who sent patches!

• RBTools is once again compatible with Mercurial 2.x. This regressed in 0.7.6.
• Some error displays are fixed when using the version of Python shipped with macOS 10.11.
• Perforce gained the ability to post against null client roots, and fixed posting ranges of submitted changelists.
• Repository lookups utilizing mirror paths or Subversion UUIDs now work once again. These regressed in 0.7.6.
• rbt post for Git now supports --exclude-patterns when using git-svn or git-p4.
• rbt land no longer crashes if it can't determine the approval state on a review request.

Improved Team Foundation Server support

The old TFS support was a bit slow, due to the way we had to interact with the Team Foundation Server command line tools. It also presented compatibility problems, as different versions of Visual Studio shipped different, incompatible versions of these tools.

We've now introduced new support that doesn't depend on their tools and is optimized for our use cases. This means better compatibility everywhere, faster posting, and new features.

To start with, we're adding the ability to post shelved changesets! You can do this by simply running:

rbt post <shelveset-name>

To begin using RBTools 0.7.7 with TFS, you will need to install our new TFS adapter by typing:

rbt install tfs

New features

We've added the ability to specify a destination tracking branch for rbt land. To choose something other than the default (say, origin/master on Git), you can now specify:

rbt land --tracking-branch <branch-name>

Want to set some some data for custom extension-provided fields on your review request when posting a new change? You're in luck! We've added a --field NAME=VALUE option to rbt post that does exactly this:

rbt post --field my_custom_field="Some value"

You'll need to use the name of the field that was registered by the extension. If this extension was written in-house, ask your administrator to give you the field IDs.

If you find yourself needing to pass --svn-prompt-password all the time for your Subversion setup, you can set SVN_PROMPT_PASSWORD in your project's or user's .reviewboardrc instead. Just set this and you'll never have to type it again:

SVN_PROMPT_PASSWORD = True

What's coming next

We're working toward a RBTools 1.0 release, which will feature enhanced support for Mercurial, new automation commands for use in the upcoming Review Board 3.0, easier setup and installation, and better display of progress when posting changes.

We're also hard at work on a rewrite of our documentation, with the aim of providing more practical, detailed setup and usage guides for RBTools. These will begin to land over the next month.

If you have any bug reports or feature requests for either RBTools or the documentation, we'd love to hear them! You can file a bug or reach out to us on our reviewboard-dev discussion list.

Earlier today, Django released a new set of security releases that address issues when running unit tests against Oracle databases and when running a Django-based application when setting DEBUG = True and ALLOWED_HOSTS = [] in a server's settings file.

Review Board should not be impacted by the Oracle issue (which would not occur in production), and we don't recommend running with DEBUG = True (plus, new sites created with Review Board 2.0+ will have a safe default for ALLOWED_HOSTS, keeping you safe). Still, we recommend that you always update to the latest Django 1.6.11.x security release anyway.

We maintain security-hardened builds of Django 1.6.x, the version series we use for Review Board 2.0 through 2.5. We've put out a new Django 1.6.11.5 release that contains these two fixes.

To upgrade to this release, run:

$ pip install -U https://downloads.reviewboard.org/releases/Django/1.6/Django-1.6.11.5.tar.gz

Or:

$ easy_install -U https://downloads.reviewboard.org/releases/Django/1.6/Django-1.6.11.5.tar.gz

We then recommend that you visit your Administration -> Security Checklist page to ensure that your ALLOWED_HOSTS and other security settings are correct.

You can always keep up on the latest Review Board security announcements by subscribing to our Official Announcements mailing list.

We have a couple of new Review Board releases for you today, including the biggest 2.5.x release yet.

Review Board 2.5.7 brings new administrative features, improvements to e-mail sending (including DMARC compatibility) and content, extension unit testing, usability enhancements, and over 40 bug fixes.

Review Board 2.0.25 brings many of those same bug fixes, along with the new extension unit testing support, for users who have not yet upgraded to 2.5.

Let's take a look at some of the major new changes in these releases.

More reliable e-mail

• E-mail has been evolving in recent years, with new starts forming to help combat spam and fraudulent e-mails. Some of these standards, like the Sender Policy Framework and DMARC, can prevent Review Board from reliably sending e-mail on behalf of users.

  In Review Board 2.5.7, we've added compatibility with these standards, ensuring that all Review Board e-mails will safely reach their destination.

• We've also added a handy new link in the Review Request Updated e-mails in Review Board 2.5.7 for showing the changes made since the previous diff. That's one less click to view an interdiff.

Easier administration

Review Board 2.5.7 adds a few new features to help administer users and settings on your install:

• It's now easier to manage users belonging to review groups, default reviewer rules, repository access lists, and other places in the administration UI. We've introduced a new widget for managing lists of users, which scales well and simplifies locating and adding new users.

• You can now safely grant users fine-grained access to the administration UI without giving them access to global Review Board settings. Simply set them as a "staff" user instead of "superuser."

Both 2.5.7 and 2.0.25 have made it easier to work with repository credentials and authentication servers:

• Hosting service credentials for repositories can now be edited simply by clicking "Edit Credentials" by the desired account on the repository page. This should make things a lot easier in the event of a password or token change on a service.

• Authentication forms for LDAP, Active Directory, and more have been organized, making it a lot easier to get going for the first time.

Extension unit testing

When writing extensions for your server, you want to make sure you can catch any breakages or changes in functionality when preparing to upgrade to the next version of Review Board. We've made it easy to write and run unit tests for your extension, using the new rbext command. Now you can make sure your extension works as expected before doing your next big server upgrade.

Lots of bug fixes

We've fixed quite a lot of bugs in these releases. We have fixes for CVS, Bitbucket, GitLab, webhooks, the API, e-mail contents, file attachment display and review, Power Pack compatibility, post-commit review, custom Markdown text fields, dashboard columns, and much more.

You can see the 2.0.25 and 2.5.7 release notes for the whole list of changes, along with upgrade instructions.

10 years ago, David Trowbridge and I (Christian Hammond) began talking about the problems and annoyances with code review, and how it could be better. Code review at the time was (usually) a very tedious process where you'd e-mail diff files around and reply to them, and while there were a couple of tools on the market, they were expensive and cumbersome.

So on September 27, 2006, ten years ago today, we landed our first commit.

r1 | chipx86 | 2006-09-27 00:25:53 -0700 (Wed, 27 Sep 2006) | 2 lines

    Add the reviewboard.

Where we were back then

Back in 2006, there was no GitHub or Bitbucket. Git was just around a year old. Subversion and Google Code were the tools choice of most open source projects. Many companies performed code reviews on whiteboards or projectors.

And people still e-mailed diffs around.

We just knew things could be better, so we began writing Review Board. We didn't know if it'd be a short-lived toy project, our new excuse for staying up all night coding, or if it could truly be more. It started off as just an experiment in improving how code review could be made better, could evolve, to make lives easier for developers.

The experiment was a success.

(We've come a long way since.)

Where we are today

Fast forward 10 years (!) and we have a product that we're proud to call our day job, a product that thousands of companies depend on every day. Hundreds of thousands of developers.

Over the years we've learned what works and what doesn't. We've greatly enhanced our code review capabilities, added support for many more types of code hosting services, wrote a powerful and comprehensive extension infrastructure and API, and helped change the world of code review for the better.

Our core team has expanded. We've put out 142 releases of Review Board alone (that's over 14 a year!), built a Review Board SaaS (RBCommons), added new enterprise-level features through Power Pack, and established support contracts with companies to help them through the good times and bad.

There are many code review tools on the market these days, and we're so glad to see that most developers no longer have to live in the dark ages of e-mailing diffs and projecting code up on walls. Throughout it all, Review Board has remained a strong, powerful, and beloved tool for so many, and we couldn't be happier.

Our users have been truly great. One company 3D printed Sparkly and Fish Trophies for us. Someone once wrote a poem for us ("Ode to Review Board"). We've been invited to give talks at big tech companies. We've mentored over 100 students as part of UCOSP and Open Academy, using Review Board development to help them prepare for their careers as software engineers.

It's been an amazing ride, and we're nowhere close to done.

Where we're going

We have several very exciting features in the works to bring your code quality to a new level. Our focus right now is on Review Board 3.0, which is bringing:

• A new and improved (but still familiar!) review experience
• Support for integrating with third-party services (like Slack, Asana, and more), allowing for as many distinct integration configurations as you need
• Built-in support for showing and handling feedback from automated code review services
• Improved search results and on-the-fly indexing, with support for Elasticsearch
• OAuth2 provider support
• Custom avatar services
• And much, much, much more

It's going to be a fantastic release. RBCommons users will get to see some of this soon!

In parallel, we've also been working on features for Review Board 4.0. The big highlight (and the feature being worked on now) is DVCS support, featuring some really useful takes on multi-commit review. We have some other great features planned, but aren't ready to announce them yet.

We've had an amazing 10 years, watching our little experiment grow and make a difference to customers around the world. We can't wait to see what the next 10 years have in store.

Happy birthday, Review Board!

Django released a new set of security releases today, designed to fix a vulnerability in the cookie parsing code when combined with usage of Google Analytics that could allow an attacker to bypass CSRF protection. (See their announcement for more details.)

We maintain security-hardened builds of Django 1.6.x, the version series we use for Review Board 2.0 through 2.5. We have put out a Django 1.6.11.4 release containing these security fixes.

To upgrade to this release, run:

$ pip install -U https://downloads.reviewboard.org/releases/Django/1.6/Django-1.6.11.4.tar.gz

Or:

$ easy_install -U https://downloads.reviewboard.org/releases/Django/1.6/Django-1.6.11.4.tar.gz

This particular vulnerability is unlikely to affect most of our users (at least as documented in Django's release notes), but we still recommend upgrading, to be safe.

You can always keep up on the latest Review Board security announcements by subscribing to Official Announcements mailing list.

HTTPoxy is an old, but recently-discussed security vulnerability affecting CGI-backed web applications (and certain client-side libraries). It allows an attacker to send a Proxy HTTP header to a vulnerable web server, and have that translate into a HTTP_PROXY environment variable, which may then be used to specify an HTTP Proxy server for use by HTTP requests initiated from the server. This happens because CGI-based web applications are provided the client's HTTP headers as environment variables, converted to uppercase and prefixed with HTTP_. This is normally not a problem, but

Effectively, HTTPoxy allows an attacker to Man-in-the-Middle HTTP requests made by the web application, intercepting traffic or returning bad data.

Don't worry, Review Board is safe!

Review Board is not vulnerable to HTTPoxy, as it doesn't use CGI. Most Review Board installs use WSGI, and some older installs use mod_python or FastCGI. None of these implementations are vulnerable (despite the "CGI" in the name "FastCGI").

We'd still recommend fine-tuning your server's settings to work around the HTTPoxy vulnerability, as a precaution, particularly if you're running anything else on the server. See the HTTPoxy Mitigation instructions for further details.

Today's release of Power Pack brings a brand new feature: Support for Visual Studio Team Services.

Formerly known as Visual Studio Online, this service provided by Microsoft allows you and your team to easily set up and work with Team Foundation Server repositories. Now, using Power Pack, you can add your repositories to Review Board and take advantage of all of our enhanced code review capabilities. See the documentation for more information on getting set up.

We've also improved the UI for PDF Review. Previously, the PDF Review UI would appear as its own independent box, separate from the rest of the review request page (including the header with the "Close," "Review," etc. actions). Now, when using Review Board 2.0 or higher, it will fit in more naturally with the rest of the page.

There are also a handful of other bug fixes for TFS-Git, anonymous users, and more. See the release notes for more information.

Review Board 2.5.6 shipped in a bit of a broken state, due to a packaging error that wasn't caught by our automated tests. This led to JavaScript failures on certain pages, like the New Review Request page.

Review Board 2.5.6.1 is out now and fixes the error. If 2.5.6 broke you, just install 2.5.6.1 and you'll be back up and running.

We're expanding our automated testing to ensure this particular problem won't happen again. Sorry for the trouble, and thanks for using Review Board!