The GitHub Blog

Starting today, diffs on prose documents are soft-wrapped.

Before:

After:

Review without scrolling, comment with ease, and stop hard-wrapping your prose documents.

It's tough to be the bearer of bad news. Fortunately, today we're making it a bit easier to quickly publish beautiful pages for you and your projects.

When you push a change to your GitHub Pages site — whether via Git command line, one of the desktop apps, or GitHub.com — we email you if for any reason we can't build your site.

Starting today, you'll also get a descriptive, human-readable error message for any failed build so that you can more easily troubleshoot what went wrong:

We've started by supporting the most common error messages seen on GitHub Pages, and will continue to roll out support for additional errors in the coming weeks.

For more information on troubled builds, see the Jekyll troubleshooting guide or contact GitHub Support. Happy publishing!

Whether it's reviewing community changes to an Open Source project, or using GitHub Flow on a private project, we all spend a lot of time looking at diffs. But to really understand a code change, we sometimes need to see more than just the default three lines of context.

Today we’re excited to announce a new feature that makes this possible. Using the new unfold button in the gutter of a diff, you can reveal additional lines of context with a click.

You can keep clicking unfold until you've revealed the whole file, and the feature is available anywhere we render diffs.

Happy code reviewing!

There are a lot of interesting people on GitHub today. Since we can't meet everyone at a conference, drinkup, or charity dodgeball game, we are hoping you can tell us a little more about yourself.

Please take a minute to fill out this short survey. You'll be helping us learn how we can make GitHub even better for you.

Cheers & Octocats!

(Also: tell your friends.)

Some GitHub user accounts with weak passwords were recently compromised due to a brute force password-guessing attack. I want to take this opportunity to talk about our response to this specific incident and account security in general.

We sent an email to users with compromised accounts letting them know what to do. Their passwords have been reset and personal access tokens, OAuth authorizations, and SSH keys have all been revoked. Affected users will need to create a new, strong password and review their account for any suspicious activity. This investigation is ongoing and we will notify you if at any point we discover unauthorized activity relating to source code or sensitive account information.

Out of an abundance of caution, some user accounts may have been reset even if a strong password was being used. Activity on these accounts showed logins from IP addresses involved in this incident.

The Security History page logs important events involving your account. If you had a strong password or GitHub's two factor authentication enabled you may have still seen attempts to access your account that have failed.

This is a great opportunity for you to review your account, ensure that you have a strong password and enable two-factor authentication.

While we aggressively rate-limit login attempts and passwords are stored properly, this incident has involved the use of nearly 40K unique IP addresses. These addresses were used to slowly brute force weak passwords or passwords used on multiple sites. We are working on additional rate-limiting measures to address this. In addition, you will no longer be able to login to GitHub.com with commonly-used weak passwords.

If you have any questions or concerns please let us know.

GitHub has a long tradition of supporting developer communities throughout the world. We throw drinkups, speak at and sponsor conferences, and host training events in most corners of the globe.

However, with the exception of a few talks and drinkups in Cape Town, we've not yet had much of a chance to see what's going on in the burgeoning sub-Saharan tech scene.

We had heard that several African countries were rapidly growing new and innovative tech communities, but very little is being said about how they operate. So last month @nrrrdcore, @luckiestmonkey and I decided to check it out for ourselves.

It just so happened that a group of like-minded developers and designers from Europe called The AfricaHackTrip, were also planning a very similar trip. So we reached out to them to see if we could tag along and help out in any way. We ended up sponsoring the Hackathons and BarCamps they had organised in 4 African cities and participating in a couple of them as well.

Rwanda

Our first stop was Kigali, Rwanda. Here we joined the AfricaHackTrip halfway into their adventures and took part in their BarCamp and Hackathon at the Office co-working space.

We met a ton of awesome techies and had great discussions about topics ranging from Open Source Software schools to time travel. On the hackathon day we discovered how some Rwandan hardware hackers are using Arduinos to solve rural farming problems and that reliance on decent internet connectivity is a big problem for developers there. Big enough that one group created a hack project that would monitor different Rwandan wifi networks at the same time:

Tanzania

In Dar es Salaam the BarCamp and Hackathon events were held at the awesome Buni co-working space. Across the trip we noticed how technology hubs are working together to create vibrant communities. It wasn't uncommon to see the manager of one hub helping out at events at another.

Dar es Salaam was just as exciting as Kigali. People discussed local online payment systems and hacked on mapping solutions for Tanzanian health initiates. At a Git & GitHub workshop that we held at the Kinu co-working space 50 people suddenly turned up – excited and ready to learn.

Kenya

Once the AfricaHackTrips in Kigali and Dar es Salaam had finished, I then travelled on to Nairobi to check out the DEMO Africa conference and meet some of the inspiring startups coming out of Africa.

I also spent a day at the iHub, Nairobi's centre for everything tech. Here I met teams from Ushahidi and BRCK, as well as Akirachix – who are taking underprivileged women from Nairobi, teaching them how to code, and mentoring them into programming jobs.

A developing world

We'd like to continue supporting developer communities throughout Africa and the developing world. If you're putting on a conference, hackathon or meet-up and you're in search of a sponsor, please get in touch through our community page. Or, if you're running an innovative tech space or developer-community project, get in touch and we'll see how we can help!

There's a lot happening on GitHub. As we reach closer and closer to 10 million repositories, there's an astounding amount of activity happening every day. Our trending page is a great place to keep up with new & interesting projects on GitHub… but who has time to visit a website every day?

Enter our new Explore email. You can now subscribe to an email (delivered daily, weekly, or monthly) to keep up with what's popular on GitHub.

Jump on over and subscribe to your flavor today.

Octokit is a family of client libraries for the GitHub API. Back in May, we released Octokit libraries for Ruby and Objective-C.

Today we're releasing the third member of the Octokit family, Octokit.net, the GitHub API toolkit for .NET developers.

Octokit.net is used in GitHub for Windows and provides an async-based API using HttpClient. Octokit.net requires .NET 4.5 or later.

The "Octokit" package is available through NuGet. For Reactive Extensions (Rx) fans, we also have an IObservable-based "Octokit.Reactive" companion package.

We can't wait to see what you'll build with it.

We've made some significant upgrades to the network infrastructure powering GitHub, and it's time to turn off some of the old gear. We've updated DNS records to point at our new IP space, but continue to see a steady trickle of requests to IP addresses long since removed from DNS.

On Tuesday, November 5th 2013, at 12pm Pacific Time, we'll stop serving all HTTP, Git, and SSH requests to IP addresses that aren't returned from DNS queries for the following domains:

• github.com
• gist.github.com
• api.github.com
• raw.github.com
• ssh.github.com
• wiki.github.com
• assets.github.com

This won't affect you if you don't have any /etc/hosts entries for any of the above domains. However, if you've added github.com or any of the listed domains to /etc/hosts over the last few years, you'll need to remove those entries or GitHub will stop working for you next Tuesday at noon. Take a quick look at your /etc/hosts and/or your Puppet/Chef manifests to make sure you're ready to go!

Please note that our DNS servers are configured to automatically return the IP address of a random, healthy load balancer for queries for the above records. If you have an existing /etc/hosts entry, we highly recommend not replacing it, but rather removing it entirely.

Update: If you're on Windows, you'll want to check %SystemRoot%\system32\drivers\etc\hosts for anything matching github.com. If there are no entries there and you're still seeing a warning on GitHub.com, please send your network administrator a link to this blog post!

Today we released an update to GitHub for Windows allowing you to quickly see when a branch is no longer in sync with its remote.

Right next to the sync button you'll now see how many commits ahead and behind your local branch is compared to its remote. We'll automatically update it for you or you can press F5 to refresh it manually.

In addition, you can now press the sync button at any time to get the latest changes from the remote, even before GitHub for Windows has detected them.

If you've already got GitHub for Windows installed you'll get this release delivered as an update. If you don't it's available over at windows.github.com.

Happy syncing!

If you've been keeping an eye on your cookies, you may have noticed some recent changes GitHub has made to how we track your session. You shouldn't notice any difference in session behavior (beyond the new ability to revoke sessions), but we'd like to explain what prompted the change.

Replay attacks on stateless session stores have been known and documented for quite some time in Rails and Django. Using signed cookies for sessions is still incredibly easy to use and scales to high traffic web apps. You just need to understand its limitations. When implementing authentication, simply storing a user ID in the session cookie leaves you open to replay attacks and provides no means for revocation.

The other option is to switch to persisted storage for sessions. Either using a database, memcache or redis. On a high traffic site this may be a performance concern since a session may be allocated even for anonymous browsing traffic. Another downside, there is no clear insight into these sessions. They are stored as serialized objects. So there's no way to query the store to see if a user has any sessions. It's all abstracted away by Rails.

Hybrid Cookie Store / DB approach

After ruling out Rails’ built in method for DB backed sessions, we decided that the concept of user sessions ought to be treated as a first class domain concern. Something with a real application API we can query, test and extend with other app concerns.

The UserSession class is just a normal ActiveRecord class like any other. There's no excess Rails abstraction layer between it. We've extended it with other concerns such as manual revocation, sudo mode tracking and data like IP and user agent to help users identify sessions on the active sessions page.

class UserSession < ActiveRecord::Base
  belongs_to :user
  before_validation :set_unique_key
  scope :active, lambda {
    { :conditions => ["accessed_at >= ? AND revoked_at == NULL", 2.weeks.ago] }
  }
  def self.authenticate(key)
    self.active.find_by_key(key)
  end
  def revoke!
    self.revoked_at = Time.now
    save!
  end
  def sudo?
    sudo_enabled_at > 1.hour.ago
  end
  def sudo!
    self.sudo_enabled_at = Time.now
    save!
  end
  def access(request)
    self.accessed_at = Time.now
    self.ip          = request.ip
    self.user_agent  = request.user_agent
    save
  end
  private
    def set_unique_key
      self.key = SecureRandom.urlsafe_base64(32)
    end
end

Staying true to the restful authentication spirit, SessionsController#create creates a new UserSession and SessionsController#destroy deletes it.

A separate cookie called user_session is set referencing the record unique random key. Only signed in users allocate this record. Anonymous traffic to GitHub never creates junk data in our sessions table.

We still have our signed cookie store around as session in our controllers. This handles non-sensitive data like flash notices and multi-step form state. Then we have a separate user_session helper that references the current user’s session record.

This infrastructure change took a few months. For a month, we ran both the old session code path on this new user session path at once. This allowed users to transition over to the new cookie without noticing.

Overall, we are pretty happy with the change. It has made our authentication logic much more clear and explicit. This opens up some new potential now that we have the data on the server.

Governments at all levels have been using GitHub for some time now to build better, more accessible websites, publish laws and data, and even collaborate on policies themselves.

Today we're proud to announce the launch of government.github.com, a website dedicated to showcasing the amazing efforts of public servants and civic hackers around the globe.

The site also features an up to date list of all the city, state, and national government organizations on GitHub. Don't see your local government listed? Tell them why they should be.

If you're a government employee that has a story to tell, the entire site is open source, and we'd love for you to submit your story.

Happy open governmenting, and look for your local government posting on GitHub sometime Soon™.

To follow up with our recent two-factor authentication security feature, we are giving users more insight into their active browser sessions.

Under Account settings > Security History you will see a list of all your active sessions with the ability to remotely revoke them.

Today we’re happy to share some shiny visual updates to GitHub for Windows. You’ll notice some big layout changes, as well as many small improvements throughout. The result is a lighter and brighter user experience.

History on the left-hand side

Just as we read from left to right, information in apps typically flows from left to right. In the repository view, you’ll now find the list of past commits on the left, and the selected commit to the right.

Wrapping diffs

Not a big fan of horizontal scrollbars? We hope you haven’t bought that fancy dual-scroll mouse, because long diff lines now wrap. You can review changes without having to scroll bi-directionally.

Relative commit times

We've moved to using relative times rather than just a date. Relative time is not only time-zone agnostic, but also more relatable than a specific date. The Windows team has people in Australia, Sweden and the US. Our commit history is filled with changes coming in at all hours. We hope folks who work on open-source projects or in distributed teams in general will enjoy this as much as we will.

Grouped actions

Did you know that you can easily jump to a commit on github.com? You’ll now see all actions related to commits grouped together below the commit header, making them easy to discover.

A bit of space

The new design makes great use of typography and white space for grouping and separating elements. Boxes can do a good job of grouping, but they come with the cost of introducing a lot of visual noise.

Hot off the press

If you've already got GitHub for Windows installed you'll get this release delivered as an update. If you don't it's available over at our newly updated website windows.github.com. Go check it out and download the latest version.

Hot on the heels of checking out pull requests, you can now open files in GitHub for Mac and GitHub for Windows straight from pull requests and branches!

You can see the new "Open" button in pull requests:

And when viewing a file on a branch:

Clicking it will open GitHub for Mac or GitHub for Windows, clone the repository (if you don't have it), automatically switch to the branch containing the changes, and finally open the file for editing in its default application.

We're hoping that this makes it much easier to address pull request comments!