Read our official statements regarding recent executive orders and find resources to help you take action. Learn more
Humans need at least 3.5 contribution mugs worth of water every day. This 18-ounce mug can help contribute to even the most demanding of hydration habits. Mix the contribution graph with coffee, tea, water, ice cream, cereal, soup or even your pet goldfish. You decide what goes in the mug, we won't judge. Get the Contribution Mug in the GitHub Shop.
In honor of our Bug Bounty Program's third birthday, we kicked off a promotional bounty period in January and February. In addition to bonus payouts, the scope of the bug bounty was expanded to include GitHub Enterprise. It may come as no surprise that including a new scope meant that the most severe bugs were all related to the newly included target.
There was no shortage of high-quality reports. Picking winners is always tough, but below are the intrepid researchers receiving extra bounties.
The first prize bonus of $12,000 goes to @ilektrojohn for their GitHub Enterprise SAML authentication bypass report which allowed an attacker to construct a SAML response that could arbitrarily set the authenticated user account. You can read more about the story on their blog.
The second prize bonus of $8,000 goes to @iblue for their remote code execution bug found in the GitHub Enterprise management console. This was due to a static secret mistakenly being used to cryptographically sign the session cookie. The static secret was intended to only be used for testing and development. However, an unrelated change of file permissions prevented the intended (and randomly generated) session secret from being used. By knowing this secret, an attacker could forge a cookie that is deserialized by Marshal.load, leading to remote code execution.
The third prize bonus of $5,000 goes to @soby for their report of another GitHub Enterprise SAML authentication bypass. This attack showed it was possible to replay a SAML response to have our SAML implementation use unsigned data in determining which user account was authenticated.
The best report bonus of $5,000 goes to @orangetw for their report of Server-Side Request Forgery. This report involved chaining together four vulnerabilities to deliver requests to internal services that end up executing attacker-controlled code. The reporter supplied a clear explanation of the problem through each step and included proof-of-concept scripts for the entire journey. While this report did not earn a prize for being the most severe, it is exactly the type of report we want to encourage reporters to submit.
We received a wonderful Christmas gift from @orangetw with a SQL Injection bug on GitHub Enterprise. You can read more about how they learned Rails in three days before finding the bug.
A theme we've seen continue over the years is paying out for bugs that aren't in our own code but in browsers. 2016 was no exception with @filedescriptor's report of funky Internet Explorer behavior detailing how a triple-encoded host value in a URL is handled in redirects.
Lastly, Unicode gonna Unicode. @jagracy found a way to exploit the way Unicode was normalized in our code and in our database engine to deliver password reset emails to entirely different addresses than what were intended.
Our "Two Years of Bounties" post has detailed stats for our submissions during the first two years of the program. These years saw a total payout of $95,300 across 102 submissions out of a total of 7,050 submissions (1.4% validity rate). So far in the third year of the program, we have paid out for 73 submissions for a total of $81,700. Many of these reports fall into our "$200 thank you" bucket. These are issues that we do not consider severe enough for an immediate fix, but that we still want to reward our researchers for. Forty-eight of these issues were deemed high enough risk to warrant a write-up on https://bounty.github.com. We saw a total of 48 out of 795 valid reports, bringing our validity rate to 6%.
In 2016, we saw a slight decrease in the number of reports compared to the average of the previous two years. While we can't know for certain, we suspect this is due to the ever-decreasing presence of "low hanging fruit." Unfortunately, we saw an increase in the number of "critical" reports. All other categories saw a decrease in the number of reports.
Out of the accepted reports, we saw some notable changes in the type of vulnerability reports submitted. Many categories such as XSS, Injection, and CSRF saw a decrease in reports. Notably, the number of valid CSRF reports for 2016 was zero. At the same time, we saw an increase in session handling bugs, sensitive data exposure, and missing function level access controls.
In April of 2016, we transitioned to the HackerOne platform. The graphs will not include all data for the year, unfortunately, but the data is still interesting. Notably, even though we had run a public bounty for almost 2.4 years, we still experienced a large spike upon announcing the transition, just like many programs' initial public launch.
We've also been able to track new data via the platform. For example, our average response was about 16 hours and our time to resolution was about 28 days. Tracking this data and keeping it within acceptable bounds will help ensure our program continues to run smoothly and efficiently.
We continue to see rewards being donated to charities. We absolutely love donating bounties, and we match all contributions. This year saw donations to Doctors without Borders and the Electronic Frontier Foundation (EFF).
We also sponsored an event that was aimed at helping people from under-represented backgrounds participate in bug bounties. The h1-415 event saw attendance from groups like Hack the Hood, Women in Security and Privacy (WISP), FemHacks, Lairon College Cyber Patriots, and /dev/color. Hack the Hood was nice enough to make a video from the event.
In 2016, we've learned a lot about running a bug bounty program and we've continued to uncover sharp edges of our services and codebase. Our program will continue to evolve to engage and support the community of bounty hunters that have made this program successful. We look forward to your submission in our fourth year of the program!
Best regards and happy hacking,
Starting today, all Markdown user content hosted in our website, including user comments, wikis, and .md files in repositories will be parsed and rendered following a formal specification for GitHub Flavored Markdown. We hope that making this spec available will allow third parties to better integrate and preview GFM in their software.
The full details of the specification are available in our Engineering Blog.
This project is based on CommonMark, a joint effort to specify and unify the different Markdown dialects that are currently available. We've updated the original CommonMark spec with formal definitions for the custom Markdown features that are commonly used in GitHub, such as tables, task lists, and autolinking.
Together with the specification, we're also open-sourcing a reference implementation in C, based on the original cmark parser, but with support for all the features that are actively used in GitHub. This is the same implementation we use in our backend.
A lot of care and research has been put into designing the CommonMark spec to make sure it specifies the syntax and semantics of Markdown in a way that represents the existing real-world usage.
Because of this, we expect that the vast majority of Markdown documents on GitHub will not be affected at all by this change. Some documents sporting the most arcane features of Markdown may render differently. Check out our extensive GitHub Engineering blog post for more details on what has changed.
There's a new way to reinforce your team's code reviews. Now you can specify who in your organization can dismiss reviews on a protected branch.
In the last year, we've been updating pull requests with features that help teams give feedback and make sure only the highest quality code makes it into their projects. You can leave, manage, request, and dismiss reviews, as well as protect branches and limit merging rights. With restricted review dismissals, you can also ensure important feedback gets addressed.
Completely remove the ability to dismiss reviews on a protected branch or restrict that ability to a subset of users or teams specified in your branch protection settings for any organization repository.
Git helps millions of developers write and collaborate on code, but it's not always a practical choice for building games. With the GitHub for Unity extension, Unity game developers (artists and programmers alike) can better integrate Git and GitHub into their workflow, even if they're versioning large binary assets.
The GitHub for Unity extension integrates Git and GitHub directly into the Unity Editor. You can easily configure, collaborate, and manage your Git project in a dedicated window. The extension also includes Git LFS v2.0 support to store large binary assets and introduces file locking to help communicate with your team that you are working on difficult-to-merge files.
The GitHub for Unity extension is a first step towards unifying the GitHub and Unity workflows, and we'd love to hear your feedback to help guide us in the right direction. Watch for an alpha release over the next few weeks. We'll be making the project open source and publishing the extension in the Unity asset store soon after.
Many thanks to Emil "AngryAnt" Johansen for all his help in getting this project up and running.
Sign up now to get access to the GitHub for Unity plugin preview.
Today we're announcing the next major release of Git LFS: v2.0.0.
The official release notes have the complete list of all the new features, performance improvements, and more. In the meantime, here's our look at a few of our newest features:
With Git LFS 2.0.0 you can now lock files that you're actively working on, preventing others from pushing to the Git LFS server until you unlock the files again.
This will prevent merge conflicts as well as lost work on non-mergeable files at the filesystem level. While it may seem to contradict the distributed and parallel nature of Git, file locking is an important part of many software development workflows—particularly for larger teams working with binary assets.
# This tells LFS to track *.tga files and make them lockable.
# They will appear as read-only on the filesystem.
$ git lfs track "*.tga" --lockable
# To acquire the lock and make foo.tga writeable:
$ git lfs lock foo.tga
# foo.tga is now writeable
$ git add foo.tga
$ git commit ...
$ git push
# Once you're ready to stop work, release the file so others can work on it.
$ git lfs unlock foo.tgaGit LFS v2.0.0 also comes with a host of other great features, bug fixes, and other changes.
Our transfer queue, the mechanism responsible for uploading and downloading files, is faster, more efficient, and more resilient to failure.
To dive in, visit our release notes to learn more.
Git LFS has tremendously improved internals, particularly in Git and filesystem operations. push and pull operations have been optimized to run concurrently with the underlying tree scans necessary to detect LFS objects. Repositories with large trees can begin the push or pull operation immediately, while the tree scan takes place, greatly reducing the amount of time it takes to complete these operations.
The mechanism that scans for files tracked by LFS has been enhanced to ignore directories included in your repository's .gitignore, improving the efficiency of these operations.
In Git LFS v1.5.0, we introduced the process filter (along with changes in Git v2.11) to dramatically improve performance across multiple platforms, thanks to contributions from @larsxschneider.
Since its release, Git LFS has benefited from the contributions of 81 members of the open source community. There have been 1,008 pull-requests, 851 of which have been merged into an official release. Git LFS would not be possible without the gracious efforts of our wonderful contributors. Special thanks to @sinbad who contributed to our work on file locking.
File locking is an early release, so we're eager to hear your feedback and thoughts on how the feature should work.
In addition, our roadmap is public: comments, questions (and pull requests) are welcomed. To learn more about Git LFS, visit the Git LFS website.
Psst! We also just announced the GitHub plugin for Unity, which brings the GitHub workflow to Unity, including support for Git LFS and file locking. Sign up for early access now.
Today we're introducing a new Business offering that brings SAML single sign-on, automated provisioning and deprovisioning, 24/5 support, and guaranteed uptime to GitHub.com. With direct access to our developer community and growing platform of integrators, teams can scale and work more efficiently using the tools they need. With the new offering, teams can work on GitHub.com or GitHub Enterprise for $21/user/month.
These new features build on how development teams already work on GitHub.com: with unlimited private repositories, team and user level permissions, pull requests, code review, and project management tools. Now, they can also access:
You might recognize some of these features from GitHub Enterprise, and you'd be right! By adding them, we hope teams will be able to manage people and tools with added security and efficiency, all while hosting code on GitHub.com. We also expect they'll spend less time on overall administration and be able to grow without the need to manually add users or manage servers.
Teams that need to host GitHub on-premises or in a private cloud can do so with GitHub Enterprise, which has also received a few updates today for performance, reliability, and pull request efficiency. Read more about the latest release.
We'll be covering the specifics of this new offering in an upcoming webcast, along with an overview of how teams use GitHub.
If you’re already using GitHub.com to host your projects, you can upgrade through your organization's Settings page. If you'd like to talk to someone first, get in touch with our Sales team—we'd be happy to help you out.
GitHub Enterprise 2.9 is now available with improvements for both developers and administrators. With this release, administrators will see improvements in reliability and developers can get more out of pull requests.
Ready to upgrade? Download GitHub Enterprise 2.9.
Now, with load balancer support, running a load balancer in front of a single GitHub Enterprise appliance or High Availability pair allows for even more reliable deployments.
We’ve also expanded installation flexibility with a new hosting option on Google Compute Engine.
Starting conversations around code is what Pull Requests and the GitHub Flow are all about. These feature enhancements make that collaboration even more efficient.
GitHub Projects can now be used at the Organization level. All users in your Organization will have access to its Projects, so you and your team can plan and manage work across repositories. With Organization-wide Projects, everyone can see what's already in motion and work together without duplicating efforts.
Upgrade to GitHub Enterprise 2.9 today to start using these features and keep improving the way your team works. You can also check out the release notes to see what else is new.
For teachers it can be a challenge to get students the help they need exactly when they get stuck, especially in large courses. But when teachers use an automated testing suite like Travis CI with their assignments, students can hone in on their mistakes and iterate to improve.
Students see the value of a test-driven workflow as they are learning, and teachers save time grading assignments: a win for everyone.
Omar Shaikh, Lecturer at San Francisco State University, saw an opportunity to improve the assignment workflow for the C++ course he took over:
"The problem with the manual submission process was that, if a student is missing a small semicolon, or they were almost correct, the TA has no way of knowing because it doesn't compile. Yes, the TA can go into the code and try to grade it, but it's very inefficient."
Exercism, a tool that helps code newbies and experienced programmers learn new languages, uses a testing framework to guide students in increments.
“It helps people who are new to programming break down problems into smaller pieces” said Exercism creator Katrina Owen, “a lot of students spent a lot of time being stuck before I introduced test suites. Seeing the green check marks when their tests pass can reassure students that they’ve mastered the skill and the problem is solved for now.”
Experienced Ruby teacher (and TravisCI engineer) Renée Hendricksen agrees: “When you have assignments that are ‘write code to get these tests to pass’ the student gets instant feedback if they are on the right track.”
“When you use a ‘test-first’ teaching method,” she explained, “students get used to reading and understanding errors early. When they start with a failing test, they can look into whether it’s an error because of setup or their application. Let the red-green-refactor guide you.”
Instead of grinding through a lot of time looking for a missing period or semicolon, teachers have insight into exactly which piece of the code didn’t pass and go from there.
For Hendrickson, a testing suite makes grading more efficient because she can see where a student needs help:
“If I see a failing test I can look there immediately and address where they struggled. If all the tests are green, I can focus on working code and give them guidance for style and composition improvement, without getting bogged down explaining syntax issues.”
Omar connects his course organization to GitHub Classroom, and then to Travis CI. While there are many ways to implement automated testing, here are the steps to implement his particular workflow:
Setting up a new individual assignment in GitHub Classroom
hwx-template (where x is the homework number).
Example of a few student repositories on Travis CI for “hw3”
Graders can look at which tests failed for insight into where students struggle with the material
If you’re ready to implement Travis CI and GitHub Classroom, here are some tools to get you started:
To help you put all of the pieces together, Omar made a video walkthrough:
This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:
Join this week’s discussion in the community forum: How to automatically gather or collect assignments?
Earlier this month, we gave you a preview of our Terms of Service update, and we asked for feedback from our community. You responded overwhelmingly! Thank you so much, everyone who sent us feedback. We heard you, and we have edited the Terms accordingly. The new Terms of Service are now effective!
We received nearly 100 comments on our proposed Terms of Service changes. A few clear themes emerged:
Several users asked us to provide a diff of the new Terms compared with the old Terms. We weren't able to, because we wrote the new Terms from the ground up; they were not an iteration of the old Terms. However, we are happy to provide a diff between the February 7 draft and the final draft. Please take a look at the changes you inspired!
Of course, the things you liked about our new Terms are still there. You'll still find:
The new Terms of Service are in effect as of today, February 28. You can accept them by clicking the broadcast announcement on your dashboard or by continuing to use GitHub. Again, thank you so much to our user community! You've helped us make our Terms better. Please let us know if you have any questions about the new Terms, or if we can help you going forward.
With the the Game Developers Conference (GDC) and Virtual Reality Developers Conference (VRDC) in San Francisco next week, that means it's time for our annual GDC Party.
Please swing by GitHub HQ on Tuesday, February 28th at 7 PM, and feel free to bring your laptops and other devices, show off your games, and meet people who love games as much as you do. We'll supply the drinks, Wi-Fi, and Octocat stickers <3
Our friends from itch.io, Ludum Dare, and the Museum of Digital Art and Entertainment will be there with a collection of fun party games - old school classics, weekend game jam entries, and the latest indie games. We may have one or two surprises too…
Please note: GDC/VRDC badges or proof of registration are required for entry. All ages welcome, but please bring a valid photo ID if you're over 21 and would like to drink. We recommend showing up early to avoid disappointment (we certainly wouldn't be the first GDC party to reach capacity quickly).
Can't make it to the party? We'd still love to meet you. Please swing by booth #2210 in the Expo Hall Wednesday through Friday and say hi!
Many engineering organizations sort developers into teams like application engineering, platform engineering, web development, systems, and quality. Structuring organizations in this way can leave blind spots that exclude the people best qualified to help solve a given problem. To address this blind spot at GitHub, we've tested out a few alternative ways to organize teams by expertise, rather than by application. We refer to these highly specialized groups as ad hoc teams.
It is rare for a problem to be uniquely applicable to any one application team. Members of several other teams may be better qualified to solve a given problem. Additionally, when a problem is overwhelming to the team primarily responsible for a solution they are often left with few options for help. Why let these common issues stop you from getting the job done when you can organize folks across formal teams into highly specialized problem solving forces?
Imagine a scary situation where a security vulnerability in a JavaScript application has opened up your SQL database to malicious actors. Who would you call for help? While the application may belong to a specific project team, high profile issues like these are everybody's problem. You can immediately get more eyes on the issue by @mentioning teams that might be able to help. This may include your JavaScript developers, SQL experts, and the security team.
The image below illustrates how ad hoc teams can leverage the expertise of multiple members on different teams to solve a single problem.
If devGroupA owns the application, @mentioning all three function-oriented teams helps them reach several people who are members of all three teams but not part of their formal group. This increases devGroupA's problem-solving capacity, puts more eyes on the issue, and results in a faster solution.
We've applied this concept internally with an enterprise-scaling team made of Hubbers that design, build, support, and sell GitHub Enterprise. We encourage folks to @mention this team whenever a customer is planning to scale up their use of GitHub in any aspect. Team members also happily @mention the whole crew whenever interesting threads pass their way. Through this team we've been able to spread information from multiple perspectives to those consulting directly with GitHub customers without scheduling meetings with everyone synchronously present.
Give "ad hoc" teams a try in your organization and let your problems be solved!
How does Harvard's largest course, an Introduction to Computer Science, use GitHub to achieve its learning goals?
Professor David J. Malan, Gordon McKay Professor of the Practice of Computer Science at Harvard University, is dedicated to offering his students a robust learning experience. This post outlines how he uses GitHub and his own custom tools to build hands-on assignments for CS50 students.
With over 700 students, 80 staffers, and 2,200 participants in their end-of-term CS50 Fairs, CS50 has a reputation for rigor, real-life application, and engaging material.
At the same time, says Professor Malan, about half of CS50’s students typically treat the course as “terminal”— as their one and only course in computer science. So the projects touch on applications in a variety of fields, from social sciences and humanities to medicine and finance.
Malan says of the learning goals of CS50: “We want to provide students with a solid foundation in computer science so that they are well prepared for any field. And also bring to bear some practical skills to that world. So that is actually tied in with our adoption of GitHub this past year.”
The mental model for cloning, branching, opening pull requests, or pushing can be tricky for newbies just starting out. As a way to onboard students, Malan wrote a command-line tool that wraps a sequence of Git commands called submit50. They developed submit50 to not “reinvent the wheel” with a new submission system, but to create space for students to grow into comprehensive GitHub use as their learning evolves beyond CS50. Says Malan:
One goal was to have students graduate, so to speak, from the class actually having a GitHub account. And even though they don't keep their work in public portfolios for the course, the hope is that they'll have at least enough understanding of GitHub that they can use it after the term ends for personal projects.
submit50CS50 uses the structure of one branch per problem, and students engage Git and GitHub from the command line.
First, they run a command in their directory on a Linux system with a folder they wish to submit to CS50’s servers. The student then runs submit50 foo where foo is the unique identifier for that assignment.
submit50 models how Git and GitHub work while abstracting away some of the complexity:
Behind the scenes we show them the command so that through a bit of osmosis, they can infer what's actually going on.
We clone their repo, which lives in our
submit50organization. So we have full administrative rights, and students have push and pull privileges only.
The
submit50script clones that repo into a temporary directory. We do the equivalent ofrm -rfto blow away whatever is currently in there, and thengit-addthe entire contents of their current working directory into that repo, and then tag it with a tag that corresponds to the problem's name, and then push it to the server.
An example assignment is “C$50 Finance” where students build an application to simulate stock trades using Python with Flask, HTML, CSS and SQL.
Students create tables with user accounts, who can then buy and sell stocks. The application queries Yahoo Finance for stock quotes, almost in real time.
Malan is delighted to see the different personal touches students add to their projects, both functional and aesthetic.
It's a fun opportunity to introduce students to even the aesthetics of web design. Invariably the first thing students do is customize the aesthetics of the site, and then certainly there are differences in features, and we're fine with that. The assignment requires ultimately that they add a personal touch, so any feature that's not been enumerated by us they're welcome to do so long as it's of reasonable scope. So we'll get different outputs from that as well.
All students exhibit their final projects an end-of-semester “CS50 Fair.” About 2,200 people attend to see the student demos.
Malan designs the event as a kind of celebration, a capstone ritual where students can show people what they’ve made:
It's a fun way to delight in how much you've finished, particularly if new to programming just months prior. And it perhaps creates a bit of social pressure too. You know you're going to be showing this not just to your Teaching Fellow, but to your classmates, and you want to be proud of it. And so, hopefully, that incentivizes all the more of a strong finish.
Pushing beyond the boundaries of the traditional classroom, Malan connects the course materials with the news in a kind of “Daily Show” for technology, called “CS50 Live.”
Malan and the crew of Teaching Fellows take up current events, like Apple’s implementation of OpenSSL with a bug in it, and dig into the code on the show.
Professor David Malan will present CS50 along with Omar Shaikh (SFSU) and S. Monisha Pulimood (The College of New Jersey) at the Special Interest Group in Computer Science Education of the Association for Computing Machinery (ACM SIGCSE).
"How I Implemented GitHub In My Classroom"
Saturday, March 11
10:45AM-12:00PM
Room: 616/617
This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms.
Join this week’s discussion in the community forum: How to automatically gather or collect assignments?
You asked for it and we listened. Let us introduce you to Sticker Pack Five. Collect them all from the GitHub Shop!
Participating in open source can be incredibly rewarding, but it's not always obvious how to make your first contribution, start a new project, or build an active community.
To make your journey easier, we're launching the Open Source Guides, a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to open source.
Open Source Guides are a series of short, approachable guides to help you participate more effectively in open source, whether it's:
These guides aim to reflect the voice of the community and their years of wisdom and practice. We've focused on the topics we've heard about most, and curated stories from open source contributors across the web.
Want to help improve the guides? The content is open source, so head over to github/open-source-guide to participate in community discussions about best practices.
