A security warning posted on the Debian security list today warns that SSH keys generated on Debian based systems (including Ubuntu) have a highly predictable random number generator. This corroborates what we’ve been seeing here at GitHub.

Luciano Bello discovered that the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.

This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.

We STRONGLY recommend that you discontinue use of any keys generated under this configuration and update your GitHub keys after you’ve patched your Debian based system.

A list of projects extracted and open sourced from GitHub can be found on the GitHub account. We’ve also forked all the projects we are using on the site. Meta, dude.

Chris Wanstrath of Err the Blog (hey that’s me!) just posted an article covering some tasty GitHub tidbits. Range highlighting, key shortcuts, keeping dotfiles in git, and the GitHub gem are covered.

Enjoy.

script.aculo.us, the popular Prototype based JS effect and control framework, is moving its wiki to GitHub. Pitch in and help ‘em out.

The GitHub wiki system will soon undergo some changes for the better. If you’ve got ideas or feature requests, please file them at our bug tracker. Some wiki enhancement ideas have already been posted, so be sure to search before filing something new.

GitHub launched one month ago today.

The secret’s out. Popular Rails host Engine Yard recently issued a press release titled GitHub and Lighthouse Tap Private Cluster from Engine Yard. In it you can find some choice quotes from yours truly as well as juicy information on the generous cluster upon which your Git repositories and tickets are safely and securely hosted. Thanks EY!

If you’re looking for awesome, hands-on hosting, we highly recommend Engine Yard.

This afternoon we’re rolling out the ability for every public project on GitHub to, dare I say, make money. You’re now one click away from adding a Pledgie badge to any of your projects. Pledgie is a great service offering a simple and effective way to donate money to a cause worthy of your hard-earned dollars.

Turning it on is as simple as entering in your Paypal email on your repository’s edit screen:

After doing that, you’ll see one of these guys hanging out in your repo’s detail box:

That’s all there is to it, the money goes directly to your account. Don’t feel shy asking for donations, you worked hard for it!

Many users are claiming coolness boosts of 90% – 100% after installing Dr Nic’s GitHub Badge on their blog. I should know—I’m one of them. Just look at my badge:

Cool, right? Check out the good Doctor’s blog post and have at.

Tim Dysinger has a great guide on Deploying with Capistrano, Git and SSH-Agent. Check it out to learn how to deploy your web app without needing deploy keys.

New from Peepcode, Scott Chacon’s Git Internals PDF is sure to be a hit. If you’re wondering the ins and outs of Git, beyond the porcelain commands, this PDF is for you.

It also covers Git day-to-day use, workflow, and best practices. Even if you’re comfortable with Git, you’ll surely pick something up in this.

No, we’re not listed on the NASDAQ (yet), but we are open-sourcing the code that handles our service integration with the likes of Twitter, Campfire, Lighthouse, etc.

We realized there’s no way our small team can keep up with the demand, so rather than limiting the number of choices, we’ve decided to let the community pitch in if you guys and gals are interested in adding or modifying a service.

Head to the following repository for instructions on how to help:

http://github.com/pjhyett/github-services

Looks like jakobo had some hard drive troubles this weekend. Ouch. Luckily, thanks to backups and GitHub, he didn’t lose much.

I did a fresh install upgrade from Tiger to Leopard last weekend. With GMail, 1password, and GitHub, I didn’t worry that much about losing anything critical in the move. Really, there’s nothing keeping you from using GitHub in tandem with other git repository hosts. That’s kind of the point.

Distribute your data and you will have a much harder time losing it. Just ask jakobo.

Update regarding require, please read below

The next time you visit your repository’s edit screen you’ll see a new checkbox that should be pretty exciting for users hosting their RubyGem project on GitHub:

After checking that, managing your gem is as simple as managing a gemspec in your project’s root directory (example). Anytime you push a modified gemspec to GitHub, we’ll build and publish a new gem for you.

Feel free to give your open source friends a hard time when they don’t release a new gem version for a while, because they have no excuse now :-)

One concept regarding our server that bears repeating is that your gem will always be prefixed with your username. Installing mojombo’s grit gem is done via the following:

$ sudo gem install mojombo-grit
Successfully installed mojombo-grit-0.8.1

Using said gem works a couple of ways. First the regular require:

$ irb -rubygems
>> require 'grit'
=> true

Update: The following also works if you have competing versions of the same gem:

$ irb -rubygems
>> gem 'mojombo-grit'
=> true
>> require 'grit'
=> true

The namespacing may feel awkward as first, but it really lends itself to the distributed nature of the service we provide. Forking a RubyGem project shouldn’t be any more complicated than forking any other type of project.

Visit http://gems.github.com for all of the details. Enjoy!

GitHub hit a major milestone the other day, surpassing its millionth event. Events are those helpful things that show up in your dashboard, letting you know when someone makes a comment, forks a repository, is added as a member to another, and so on.

Thanks to everyone, old and new, for making this site a pleasure to work on. We have some really exciting stuff in the pipeline, so stick around!

...is coming soon. But we need your help!

Please send us any Git or GitHub related questions so we can answer them on the show. You can ask questions via email to chris@logicalawesome.com or @github a chirrp on Twitter.

While technical questions are great, so are conceptual ones. Feel free to ask about the GitHub workflow, about our setup, whatever. Sky’s the limit.

Thanks!

Speaking of GitHub as a Fluid App, I’ve whipped up a better icon. This one looks nicer in the dock and doesn’t get lost if you have a dark desktop background. Here it is superimposed on a dark gray. Enjoy!

Welp, I finally upgraded to Leopard today. And you know what that means… Fluid! Now that I can run standalone GitHub, I thought it would be fun to play with the provided JS API.

First up, your unread message count. We don’t have any polling stuff (yet), but it’ll update on every page load:

Also, if you hold down the GitHub icon there are some quick links available:

That’s it for now. I’m sure there will be more as both Fluid and GitHub grow. I’d love to figure out a way to add some useful Growl stuff.

Update: Want to try out the Thumbnail plugin on commits? Go to Preferences and click “Thumbnail,” then add these two rules:

http://github.com/*commits*  .human .message pre a
https://github.com/* .commit .message a

This’ll give you hot coverflow action for commits on your dashboard and any commit log page.

It’s almost that time. If you’re seeing the message below, please head to your account page and either upgrade your plan or take the steps necessary to limit your usage to the plan you want.

You may need to make some private repositories public, delete large repositories, or tell your friends to delete their forks of your private repository.

Questions? We’re always at support@logicalawesome.com and almost always at #github on Freenode. Also, the Google group is very helpful.

Thanks! It’s been a great first week.

Repository collaborator permissions are coming very soon. You’ll be able to give someone read, write, or admin access to your repository. To prepare for that, we’ve added an “Admin” tab to each repository and started splitting up the massive ‘edit repository’ page into sub-tabs.

Fear not, your Twitter hook didn’t disappear. It just has its own tab now.

Some people are wondering what will happen to their private repositories next Thursday if they exceed their plan’s limit. Well, they’ll simply become inaccessible. You should clone and delete them before that happens to make sure you have a local copy of your code (which is nice to have anyway).

We would never consider making your private information public.

In the past, maybe 100 years ago, I worked at a company where the diff of each commit was emailed to the developers. If anyone had a comment or question, they’d “reply-all” and top-post their remark. Efficient, but oh so messy. Especially as the threads grew.

Enter: commit comments. We saw the Django Book and instantly knew this was the best (and coolest) solution.

Leave a comment at the bottom of any commit, or on a single line. Up to you. Comments show up in your feed and each repository has its own comment feed.

On the commits log or the source browser, commits that have been commented on will be marked with a comment bubble.

Try it on the Facebox commit and have fun.

We heard you loud and clear that you wanted to integrate GitHub with your existing services without having to setup a custom post-receive service. Now, when you go to your repository’s edit screen, you’ll see the following:

We knocked out the first two services that we’re most familiar with, Lighthouse and Campfire, but expect to see more coming very soon. Feel free to request a service (or +1 the ticket if your service is already listed) so we know which are the most help to you guys.

GitHub is officially live. Thanks for the awesome beta everyone.

While you can sign up or upgrade your account now, it’ll be one week (April 17th) before we start enforcing limits. Think of this as a trial period.

We’re really proud of the site and have so many ideas for the future – this is just the beginning. While we’ve come a long way since going into beta, rather than pontificate on the journey I’ll just let our happy users speak for themselves.

Update: Oh yeah, new features: comments on commits, network graphs (check the blog post), and Campfire & Lighthouse integration.

Our goal here at GitHub is to break down the barriers that normally impede collaboration. One of the biggest challenges that we face as developers is keeping track of what other contributors have done. I’ve spent the last month working on GitHub’s answer to that problem and so we’re very pleased to announce the interactive GitHub Network Graph Visualizer!

Above you’ll see a screenshot of the network graph of my god repository (click it for the real deal). On the left hand side is a list of GitHub users. Across from each user is drawn a graph of commits. Since I’ve asked for the graph to be drawn with me (mojombo) as the root, every commit on every branch that I currently have in my repository (mojombo/god) will be graphed across from my name. If you look at the second user in the list (Bertg), you’ll see that only commits that appear in his repository (Bertg/god) but not mine are drawn across from him. The third user (kevinclark) has commits that appear in neither my repo nor Bertg’s repo. And so on.

When you look at the graph you are seeing every commit on every branch of every repository that belongs to a network. But you are seeing each commit only once. Let that sink in for a second. I find that many coders are so used to a centralized SCM that they miss the fact that our Graph Visualizer is actually showing and connecting disparate repositories. Git makes this possible and once it hits you, it can change everything.

Think of it like this. If I draw the graph with myself as root, then the graph shows a sort of to-do list of code that I haven’t pulled into my repo yet. When I want to catch up on what the community has been doing in their forks of my repo, I can hit up the graph and see immediately what others have been up to. If I were to pull in Bertg’s changes, the next time I see the graph, Bertg will no longer be shown at all because he will no longer have any commits that I do not. Keep thinking to-do list and you’ll understand the graph.

This method of drawing the graph may seem odd at first. If both Alice and I contribute to merb-core and at some point Alice pulls my commits into her repo, then I may not be shown on the network graph at all (if the graph ordered her before me). My commits would have already been drawn in her repo. It is important to realize that the graph is about code not ego. My code may be in my repository and yours and many others. Our individual repos are simply vehicles for introducing our code to the world. If we learn to let go of our code a little bit, we are rewarded ten-fold by what the community or our coworkers will do with that code.

You can move around the graph by clicking and dragging it with your mouse. If you click in the graph, then you can use the arrow keys or vim movement keys (hjkl). Hold down the shift key while hitting left or right and you’ll go to the beginning/end of the graph. Press t to show/hide the tag markers. Hover over a commit for details about it. Click on a commit to be taken to that commit in a new window (makes it easy to come back to the graph without losing your place). Click a username to redraw the graph with that person as the root.

Here’s a few more graphs that show some complex branching:

• git-wiki
• merb-plugins
• lovd-by-less

You can see the graph for any repo by clicking the Network tab.

Want to use GitHub with Fluid? We got you covered. Here’s a massive octocat for superb dock action.

Know how to add changes to a previous commit? Commit only part of a changed file? Change the message of a commit 30 commits ago?

If not, check out Ryan Tomayko’s The Thing About Git. Great post, lots of advanced Git usage in there.

Update: Hey, got a trick or two of your own? Add them to the guide!

Dustin has posted a great article comparing Git to Mercurial. He’s obviously used both extensively and gives a level headed, interesting look at how they differ.

Love the quote at the end:

Although mercurial may still feel nicer today, the change [to git] feels inevitable. This flood of people leaving centralized systems means that it’s way easier to contribute to their projects than ever before. This is the important part. In the end, we all win either way.

Eric Goodwin has posted a short tutorial entitled Pushing and Pulling Branches on GitHub. It’s a must read if you’re interested in sharing work with your peers on a branch other than master.

Last summer, before GitHub, I spent a lot of time playing with Shoes. Ruby has always been lacking in the GUI department and Shoes is a really smart, innovative, cross-platform approach to the problem.

Guess what? Yep. It’s here. Follow along at the GitHub repository and why’s excellent blog, Hackety Hack.