$ git push ... remote: Resolving deltas: 100% (2/2), completed with 2 local objects. remote: error: GH013: Your push could infringe someone's copyright. remote: If you believe this is a false positive (e.g., it's yours, open remote: source, not copyrightable, subject to exceptions) contact us: remote: https://github.com/contact remote: We're sorry for interrupting your work, but automated copyright remote: filters are mandated by the EU's Article 13. To github.com/vollmera/atom.git ! [remote rejected] patch-1 -> patch-1 (push declined due to article 13 filters)
The EU is considering a copyright proposal that would require code-sharing platforms to monitor all content that users upload for potential copyright infringement (see the EU Commission’s proposed Article 13 of the Copyright Directive). The proposal is aimed at music and videos on streaming platforms, based on a theory of a “value gap” between the profits those platforms make from uploaded works and what copyright holders of some uploaded works receive. However, the way it’s written captures many other types of content, including code.
We’d like to make sure developers in the EU who understand that automated filtering of code would make software less reliable and more expensive—and can explain this to EU policymakers—participate in the conversation.
Upload filters (“censorship machines”) are one of the most controversial elements of the copyright proposal, raising a number of concerns, including:
Upload filters are especially concerning for software developers given that:
The EU Parliament continues to introduce new proposals for Article 13 but these issues remain. MEP Julia Reda explains further in a recent proposal from Parliament.
As part of our ongoing collaboration with others affected, GitHub will help represent developers at an upcoming breakfast in Parliament on Tuesday, March 20, intended to show the human impact of this copyright proposal.
EU policymakers have told us it would be very useful to hear directly from more developers. In particular, developers at European companies can make a significant impact.
Write to EU policymakers (MEPs, Council Members, or Commissioners) and ask them to exclude “software repositories” from Article 13. Please explain how important the ability to freely share code is for software developers and how important open source software is to the software industry and the EU economy
Explain this in person to EU policymakers
GitHub can help connect you with policymakers, provide additional background, or chat if you might be interested in representing software developers in defending your ability to share code and not have your builds break. Get in touch!
Last month GitHub celebrated the fourth year of our Security Bug Bounty program. As we’ve done in the past, we’re sharing some details and highlights from 2017 and looking ahead to where we see the program going in 2018.
Last year was our biggest year yet as our Bug Bounty program continued to grow in participation by researchers, program initiatives, and the rewards paid out.
Diving straight into the numbers, we can review the details of this growth. In 2017, we reviewed and triaged a total of 840 submissions to the program. Of these submissions, we resolved and rewarded a total of 121 reports with an average payout of $1,376 (and swag!). Compared to our previous statistics for 2016, this was a significant increase from 48 out of 795 reports being resolved. In 2017, our rate of valid reports increased from 6% to almost 15%.
Our total payouts also saw a significant increase from $95,300 in 2016 to $166,495 in 2017. We attribute this to the increased number of valid reports and in October we took time to re-evaluate our payout structure. Corresponding with HackerOne’s Hack the World competition, we doubled our payout amounts across the board, bringing our minimum and maximum payouts to $555 and $20,000, bringing our bug bounty in line with the industry’s top programs.
To accelerate our program’s growth in 2017, we launched a number of initiatives to help engage researchers. Among the changes to the program was the introduction of GitHub Enterprise to the scope of the Bug Bounty program, which allowed researchers to focus on areas of our applications that may not be exposed on GitHub.com or are specific to certain enterprise deployments. In the beginning of 2017, a number of reports impacting our enterprise authentication methods prompted us to not only focus on this internally, but also identify how we could engage researchers to focus on this functionality. To promote a more targeted review of these critical code paths we kicked off two new initiatives beyond our public Bug Bounty program.
Providing researcher grants is something that has been on our radar since Google launched their Vulnerability Research Grants in 2015. The basic premise is that we pay a fixed amount to a researcher to dig into a specific feature or area of the application. In addition to the fixed payment for the grant, any vulnerabilities identified would also be paid out through the Bug Bounty program. During the beginning of the year, we identified a researcher with specialty in assessing troublesome enterprise authentication methods. We reached out and launched our first researcher grant. We couldn’t have been happier with the results. It provided a depth of expertise and review that was well worth the extra monetary incentive.
In March 2017 we launched GitHub for Business, bringing enterprise authentication to organizations on GitHub.com. We used this feature launch as an opportunity to roll out a new part of the Bug Bounty program: private bug bounties. Through a private program on HackerOne, we reached out to all researchers who had previously participated in our program and allowed them access to this functionality before its public launch. This added to our internal pre-ship security assessments with review by external researchers and helped us identify and remediate issues before general exposure. With the extra review, we were able to limit the impact of vulnerabilities in production while also providing fresh code and functionality for researchers to look into.
Internal improvements to the program have helped us more efficiently triage and remediate submissions from researchers. ChatOps and GitHub-based workflows are core to how we deal with incoming submissions. As soon as new ones arrive, we receive alerts in Slack using HackerOne’s Slack integration. From there, we can triage issues directly from chat, letting the team know which issues are critical and which can wait until later. At the end of our triage workflow, we use ChatOps to issue rewards through HackerOne, so we can close the loop and pay researchers as quickly as possible.
To support these workflows, we’ve continued to build on our Ruby on Rails HackerOne API client and extensively use these and GitHub APIs in our internal processes.
So far, these improvements have made us significantly more efficient. Our average response time in 2017 was 10 hours, valid issues were triaged to developers on average within two days, and bounties were rewarded on average in 17 days. Given the time and effort that researchers dedicate to participating in our program, we feel great about these improvements. And in 2018, we’ll continue to refine our process. We’re always looking for ways to make sure our researchers receive a prompt and satisfactory response to their submissions.
Also in 2018, we’re planning to expand the initiatives that proved so successful last year. We’ll be launching more private bounties and research grants to gain focus on specific features both before and after they publicly launch. Later in the year, we’ll announce additional promotions to continue to keep researchers interested and excited to participate.
Given the program’s success, we’re also looking to see how we can expand its scope to help secure our production services and protect GitHub’s ecosystem. We’re excited for what’s next and look forward to triaging and fixing your submissions this year!
Heading to San Francisco for the Game Developers Conference (GDC) next week? Join us at GitHub HQ on Tuesday, March 20 at 7 pm for our annual GDC Party!
Our friends from the Global Game Jam will be there celebrating their 10-year anniversary and showcasing a collection of games for you to play. Feel free to bring your laptops and other devices, show off your work, and meet people who love games as much as you do. We’ll supply the drinks, wifi, and Octocat stickers.
Note: GDC 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—it wouldn’t be the first GDC party to reach capacity quickly.
Date: Tuesday, March 20
Time: 7 pm - 12 am PT
Address: 88 Colin P Kelly Jr St, San Francisco, CA 94107
February is the shortest month, but that doesn’t mean it’s short on new releases. From games to web apps, here are some projects that caught our attention with big releases last month.
Fancy yourself a director of terminal demos? Record your next terminal session with Asciinema. It’s a delightful open source tool that records terminal sessions as characters, not video. When you play back your session on asciinema.org, you see text (not images) that your audience can copy and paste into their own terminals.
Asciinema 2.0 introduces the new asciicast v2 file format, which has reduced Asciinema’s memory use, increased the maximum length of a recording, and powers terminal-to-terminal streaming. What’s more, in-progress recordings won’t be lost if your terminal session is interrupted because the new format will let you pick up from where you left off. This calls for a party parrot.
Did you know? The new asciicast format uses the JSON Lines text format, also known as a newline-delimited JSON file, for incremental reads and writes.
There’s no doubt that this release will lead to some exciting new games. Whether it’s from learning to code with a robot pirate to riffs on old school classics, the Phaser community is a fount of creativity. Feeling inspired? Check out the guide to making your first Phaser 3 game.
Did you know? The Minecraft Hour of Code Tutorials, enjoyed by tens of millions of kids around the world, were built with Phaser.
webpack is a static module bundler. That means it takes in your application’s dependencies and turns them into a tidy, browser-friendly unit, but that’s underselling it. With a host of available plugins, webpack can transform code, images, styles, and more into static assets.
webpack 4’s banner feature is speed. There are reports of build times decreasing by 60 to 90 percent! Version 4 also introduces new defaults for development and production modes, entry points, and outputs, so you can get started without any configuration. There’s heaps more changes, too, which you can read all about in the webpack 4 release announcement.
Did you know? Webpack 4 is codenamed “Legato”, an Italian word for “tied” and a musical term which means to play notes smoothly connected. Are those speed increases music to your ears, too?
Next.js is a toolkit that helps you make server-rendered React applications. The latest release, Next.js 5, has been refactored to support webpack’s features for both client bundles and server code. On top of that, Next.js has added support for TypeScript and webpack’s CSS loaders, strengthening the toolkit’s ability to reuse existing codebases. Check out the Next.js 5 announcement because it’s an impressive release!
Did you know? You can learn Next.js at the appropriately-named learnnextjs.com.
HaxePunk helps you make games for any platform: desktop (Windows, Mac, and Linux), web, and mobile (iOS and Android). HaxePunk 4.0 has been in development for over a year and that hard work has paid off. This release introduces custom shaders, signals for hooking into various events, and a improved system for getting device input. Check out the HaxePunk 4.0 release announcement for more details.
That’s just a handful of releases you shipped last month—keep them coming! If you’ve got a release that should be on our radar, send us a note.
Like professional developers working together on code, students can use GitHub Classroom to collaborate on group projects in a shared repository. In this post, we’ll walk you through how teachers can work with GitHub teams and use GitHub Classroom to create group exercises, assign teams, and reuse existing student teams.
Before you create a group exercise, you’ll need the following:
A GitHub organization with a discount for private repositories and access to GitHub Classroom
An exercise (a repository that you have access to, which contains documentation, starter code, tests, or anything else your students need to begin work on an assignment)
A list of students, or unique identifiers like their email addresses
To get started, log in to GitHub Classroom, choose one of your classrooms, then click the New assignment button followed by Create group assignment. This brings you to the “New group assignment” page where you can provide the details of an assignment. If you don’t see your classroom listed, double check that you’ve granted that organization access to GitHub Classroom.
Then set up your group assignment just like you’d setup an individual assignment. Pick a name for your exercise, a starter repository to share, and a deadline.
When creating a new exercise, you can choose whether to reuse a set of groups from a previous assignment or name a set of new groups. If you’re reusing existing groups, then select a set of teams from the “Choose an existing set of groups” drop-down list.
If your students are going to form a new set of teams, enter a name for the set of teams in the “Create a new set of teams” field. It’s helpful to name your set of teams after their intended duration. For example, if you want to use a set of teams for one assignment, name it after that assignment. If you’d like to reuse a set of teams for a whole semester, name it after the semester or course.
When you’ve completed the form, click the “Create Assignment” button. Now it’s time to invite your students to the assignment.
On the assignment page, you’ll find a unique invitation link. Share this link with your students through your learning management system, course homepage, or however you distribute assignments. Keep in mind that anyone with the link can use it, so be careful where you share it.
If you’re using a new set of groups for this exercise, and you’d like to assign students to specific group, give your students a list of people who should join each group, along with the group’s name.
Once your students have clicked the link, they may be asked to join a group (if you’re not reusing an existing set of groups). It looks like this:
There are three common cases when organizing students into teams:
When students join their group in Classroom, a team is created on GitHub.com in your GitHub organization. Teams have pretty nifty functionality, including threaded comments and emoji support.
If you create a team for your students on GitHub.com, that team will not appear in Classroom. If you’d like to use Classroom to distribute shared repositories, then use group assignments in Classroom, not teams on GitHub.com.
When you use group assignments in Classroom, each team of students will get access to one shared repository for the exercise. Every student will be able to push and pull to their team’s repository. We recommend assigning one student per team to act as project manager to resolve conflicts or merge pull requests. If your students are new to resolving conflicting changes, they can check out our documentation to learn to manage merge conflicts.
Once your students are sorted into teams, they can start collaborating on the assignment like they would in any other repository: by pushing commits and branches, opening and reviewing pull requests, or using issues. Similarly, all of their commit history is available for you to review.
As students finish up their assignments, you can see the work they’ve done in two ways. Examine the current state of the files to see the finished product or look through the repository’s history to see how students worked together. GitHub’s “Insights” tab provides you with a picture of how your students worked together. For example, “Pulse” data gives you a timeline of your students’ pull requests, issues, and conversations, while “Contributors” graphs visualize your students’ additions and deletions.
Once students complete their projects, there are a few ways to deliver feedback, including:
If you chose to use private repositories for your assignment, your feedback will be confidential, so only you and the students in the group will see it.
Ready to give a group assignment? Get started right away in GitHub Classroom. Or check out this discussion in the GitHub Education Community on how student groups can work with GitHub teams in Classroom.