admaskan
In just a few days, we’ll be meeting all the builders, planners, and leaders defining the future of software–that’s you! But Universe isn’t just about defining what the future can be. It’s also about changing it, for good.
At Universe, we try to show GitHub’s ongoing commitment to positive change and take real steps towards greater social impact (SI). This year is no exception—but we need your help. Whether you’re attending live or via livestream, here are a few ways you can join us in making software a better place for everyone:
We’re excited to host two panel discussions with developers who are working at the intersection of open source and positive impact. Both sessions will be available on Wednesday, October 17 (Day 2) at Universe and on the livestream:
We’re hosting three livestream interviews with special SI guests as well—including our scholarship recipients and philanthropic partners. Plus, you’ll also get to see a live demo of the Mojaloop software from the Gates Foundation.
Every year, we choose several Individual Scholarship Program recipients to attend Universe. Likewise, we’ve selected three local organizations as our 2018 GitHub Universe Community Partners. This year’s partners all received free tickets to GitHub Universe to share with their respective communities:
Code Tenderloin: Code Tenderloin is a workforce development nonprofit that aims to secure long-term employment for underserved communities in San Francisco.
AnnieCannons: AnnieCannons transforms survivors of human trafficking into software professionals.
Women Who Code East Bay: Women Who Code’s mission is to inspire women to excel in technology careers.
Along with providing these organizations with a set number of free tickets, you’ll also have the opportunity to help us support them by making a personal donation during the conference. Keep an eye on the screens at Universe for a special QR code that will take you directly to each organization’s online giving site.
This year, we’ve opted to donate the proceeds from our Universe Octoshop sales to four organizations doing amazing work in the cities where GitHub has local offices. In addition to getting your hands on a golden Mona Lisa, we hope you’ll help contribute to these local organizations by picking up a few more items from the Octoshop at Universe:
There are plenty of ways to make a positive impact in your local GitHub community and beyond—and Universe is just the beginning. We can’t wait to see you there.
mbcampbell
In part one of this series, Code Climate discussed how they used GitHub Apps to improve their GitHub integration. In this post, we explore how Sentry was able to simplify their signup process, improve security, and create a better experience for users by upgrading to GitHub Apps. Sentry explains how they used GitHub’s new guide on migrating OAuth apps to GitHub Apps, and what they learned in the process.
As source code management and error monitoring solutions, GitHub and Sentry work together to help developers improve their code and their productivity. After you ship a project in GitHub, Sentry alerts you to any errors or bugs, helping you understand what’s happening in production, and making it easier to start triaging, assigning, and fixing the problem.
The newest Sentry integration release provides GitHub users with faster sign-in, flexible repository permissions, and an easier organization-wide setup. For the first time, GitHub Enterprise users can also take advantage of these useful features.
Sentry moved to GitHub Apps for two reasons:
GitHub Apps enabled Sentry to provide users with a way to install an app to an organization, in addition to an individual account. This “future-proofs” the GitHub integration for the organization. Prior to GitHub Apps, if the credentials of the user who set up the integration became invalidated (for instance, they left the company, and their GitHub and Sentry credentials were revoked), the integration would break for all members of their organization. With GitHub Apps, Sentry is able to link the integration to the organization itself, providing a more robust experience when staff changes.
GitHub Apps allows Sentry users to be more selective in which repositories they give Sentry permission to access. While Sentry only used write access for creating new issues in GitHub, the old integration still required users to provide read/write permissions to all their repositories—even if it was only to use read access to the repository’s commit data. For Sentry’s releases feature to be implemented correctly, Sentry needs access to issues, but not to everything. This level of granularity didn’t exist before, but now, security-minded users can select specific repositories for which Sentry is granted access.
In addition to easily configuring repository and issue linking organization-wide, switching to Apps allowed Sentry to more efficiently authenticate users. Sentry’s new “sign-in to Sentry with GitHub” feature came as a result of this new functionality.
“In summary: transitioning from OAuth to GitHub Apps created a safer, more robust experience. The benefit we were able to bring to our users was well worth the effort”
-Meredith Heller, Software Engineer at Sentry.io and builder of Sentry’s integration with GitHub Apps
Upgrading to a GitHub App did not require touching Sentry’s old OAuth integration—Sentry’s team built it from scratch. Because of a recent framework Sentry put in place for integrations, the GitHub App was lightweight to implement and the documentation made building the GitHub App easier. It fit well with how Sentry is modeled—organizations are at the top of the hierarchy that own projects, and consist of teams of members. Since GitHub Apps allows Sentry to connect a Sentry organization with a GitHub organization (instead of a GitHub user), it complemented the existing architecture well.
Starting from scratch to rebuild the integration with Apps was the right decision. Like a puzzle with the wrong pieces, trying to re-work strictly from old code was not possible. In order to rebuild the pipeline, referencing the old code while working within a new structure worked best.
A couple of gaps that were discovered regarded a lack of “best practices” around workflow. Sentry needed to install the app on the GitHub side, which included establishing a cadence of going back and forth between the two platforms. This included redirecting from Sentry to GitHub, picking the repositories, and then redirecting back to Sentry. Additionally, a lot of information was stored in the old app, so Sentry engineers needed to be careful to not delete any information that could cause damage for users.
In short, the upgrade went well! Sentry’s new integration updates could not have happened without switching to Apps, and as such, the integration with GitHub is stronger for the developers who rely on it. Additionally, combining the integration with the identity management portion of what Sentry built (“sign-in to Sentry with GitHub”) saved time as the OAuth login used the same code to set up the application.
Through GitHub Apps, Sentry was able to consolidate all parts of the integration through one channel. While Sentry previously had separate authentication mechanisms powering issue tracking, release tracking, and the login button, all features are now powered by GitHub Apps. This was helpful for Sentry to keep the integration code concise, as well as streamline user experience.
“Overall, our application is a lot cleaner, and saves us maintenance time since we engineered the switch, as we only have to manage one app on GitHub’s side of things.”
-Meredith Heller, Sentry.io
If you’re interested in testing out how you can use Sentry to keep track of your errors in GitHub (and want to see our GitHub Apps workflow in action) check it out in the GitHub Marketplace! And, because Sentry is open source, you can check out all the code that went into building the integration.
sguthals
In early September, we released a new extension to the Visual Studio Marketplace that supports GitHub pull requests. On October 17, day two of GitHub Universe, we’ll share the stage with the Visual Studio Code Team at Microsoft to give you updates and insight into how we are building the extension during our talk Cross Company Collaboration: Extending GitHub to a New IDE.
We design GitHub for developer experience—so you can effectively collaborate and build great software. To bring you a user-friendly experience that invites novice and seasoned developers alike, it’s important we identify new opportunities. We’ve been working since 2015 to provide a GitHub experience that meets you where you spend the majority of your time: in your editor.
As .NET developers writing in Visual Studio, we recognized a large gap in the ability to collaborate in this environment. In 2015, we brought all Visual Studio developers an extension that supports GitHub.com and GitHub Enterprise engagements within the editor. And today, you can complete an entire pull request review without ever leaving Visual Studio.
Not a .NET developer on Windows? No problem! We also support a first class Git and GitHub experience for Atom developers. Access basic Git operations like staging, commiting, and syncing, alongside more complex collaboration with the recently-released pull request experience.
Unity game developers can now use Git within Unity for the first time to clone and sync with GitHub.com and lock files, including large assets that game developers often have in their projects.
In Winter 2017 we started planning our integration with VS Code after seeing how it influenced developers around the world. With a basic pull request experience in both Visual Studio and Atom, we knew we wanted to start with that level of collaboration.
In Spring 2018, we reached out to the VS Code Team and discovered that, since they were building VS Code on GitHub, they felt they were missing that collaboration piece in their editor.
VS Code developers now have the first iteration of a pull request review experience within VS Code. With a small group of people, we launched the public preview of the GitHub Pull Request Extension in September 2018.
This new extension gives developers the ability to:
Thanks to Kenneth Auchenberg (Microsoft), Rachel Macfarlane (Microsoft), Kai Maetzel (Microsoft), Peng Lyu (Microsoft), Sarah Guthals (GitHub), Andreia Gaita (GitHub), and Ashi Krishnan (GitHub) for your continued work on this extension. :sparkles:
Want to learn more? Join us at GitHub Universe 2018 on October 17 at 10:15am. We’ll demo the extension for you, give you an update on what we’re releasing next, and show you how you can contribute. If you can’t make it to San Francisco in time, tune into the livestream on githubuniverse.com.
As always, you can reach out to the Editor Tools Team by tweeting at (@githubvscode) or joining the conversation in our open source repository. And if you’d like to participate in usability studies around our extension, we invite you to fill out a short survey.
If you’re interested in the any of the extensions mentioned in this post, check out previous posts or drop into our GitHub for Visual Studio, GitHub for Atom, and GitHub for Unity repositories.
bathompso
Last year, we released security alerts that track security vulnerabilities in Ruby and JavaScript packages. Since then, we’ve identified more than four million of these vulnerabilities and added support for Python. In our launch post, we mentioned that all vulnerabilities with CVE IDs are included in security alerts, but sometimes there are vulnerabilities that are not disclosed in the National Vulnerability Database. Fortunately, our collection of security alerts can be supplemented with vulnerabilities detected from activity within our developer community.
There are many places a project can publicize security fixes within a new version: the CVE feed, various mailing lists and open source groups, or even within its release notes or changelog. Regardless of how projects share this information, some developers within the GitHub community will see the advisory and immediately bump their required versions of the dependency to a known safe version. If detected, we can use the information in these commits to generate security alerts for vulnerabilities which may not have been published in the CVE feed.
On an average day, the dependency graph can track around 10,000 commits to dependency files for any of our supported languages. We can’t manually process this many commits. Instead, we depend on machine intelligence to sift through them and extract those that might be related to a security release.
For this purpose, we created a machine learning model that scans text associated with public commits (the commit message and linked issues or pull requests) to filter out those related to possible security upgrades. With this smaller batch of commits, the model uses the diff to understand how required version ranges have changed. Then it aggregates across a specific timeframe to get a holistic view of all dependencies that a security release might affect. Finally, the model outputs a list of packages and version ranges it thinks require an alert and currently aren’t covered by any known CVE in our system.
No machine learning model is perfect. While machine intelligence can sift through thousands of commits in an instant, this anomaly-detection algorithm will still generate false positives for packages where no security patch was released. Security alert quality is a focus for us, so we review all model output before the community receives an alert.
Interested in learning more? Join us at GitHub Universe next week to explore the connections that push technology forward and keep projects secure through talks, trainings, and workshops. Tune in to the blog October 16-17 for more updates and announcements.
peff
The Git project has disclosed CVE-2018-17456, a vulnerability in Git that can cause arbitrary code to be executed when a user clones a malicious repository. Git v2.19.1 has been released with a fix, along with backports in v2.14.5, v2.15.3, v2.16.5, v2.17.2, and v2.18.1. We encourage all users to update their clients to protect themselves.
Until you’ve updated, you can protect yourself by avoiding submodules from untrusted repositories. This includes commands such as git clone --recurse-submodules and git submodule update.
GitHub Desktop versions 1.4.1 and older included an embedded version of Git that was affected by this vulnerability. We encourage all GitHub Desktop users to update to the newest version (1.4.2 and 1.4.3-beta0) available today in the Desktop app.
Atom included the same embedded Git and was also affected. Releases 1.31.2 and 1.32.0-beta3 include the patch.
Ensure you’re on the latest Atom release by completing any of the following:
In order to be protected from the vulnerability, you must update your command-line version of Git, and any other application that may include an embedded version of Git, as they are independent of each other.
Neither GitHub.com nor GitHub Enterprise are directly affected by the vulnerability. However, as with previously discovered vulnerabilities, GitHub.com will detect malicious repositories, and will reject pushes or API requests attempting to create them. Versions of GitHub Enterprise with this detection will ship on October 9.
This vulnerability is very similar to CVE-2017-1000117, as both are option-injection attacks related to submodules. In the earlier attack, a malicious repository would ship a .gitmodules file pointing one of its submodules to a remote repository with an SSH host starting with a dash (-). The ssh program—spawned by Git—would then interpret that as an option. This attack works in a similar way, except that the option-injection is against the child git clone itself.
The problem was reported on September 23 by @joernchen, both to Git’s private security list, as well as to GitHub’s Bug Bounty program. Developers at GitHub worked with the Git community to develop a fix.
The basic fix was clear from the report. However, due to to the similarity to CVE-2017-1000117, we also audited all of the .gitmodules values and implemented stricter checks as appropriate. These checks should prevent a similar vulnerability in another code path. We also implemented detection of potentially malicious submodules as part of Git’s object quality checks (which was made much easier by the infrastructure added during the last submodule-related vulnerability).
The coordinated disclosure date of October 5 was selected by Git developers to allow packagers to prepare for the release. This also provided hosting sites (with custom implementations) ample time to detect and block the attack before it became public. Members of the Git community checked the JGit and libgit2 implementations. Those are not affected by the vulnerability because they clone submodules via function calls rather than separate commands.
We were also able to use the time to scan all repositories on GitHub for evidence of the attack being used in the wild. We’re happy to report that no instances were found (and now, with our detection, none can be added).
Please update your copy of Git soon, and happy cloning!
