Contents hide

The GitHub Blog

Updates, ideas, and inspiration from GitHub to help developers build and design software.

Securing software, together 18 Sep 2019, 5:26 pm

Software powers virtually everything around us. There is software behind the things we build, the medicine we take, and even the food we eat. Every new breakthrough will be made with the help of software. It is increasingly a challenge to identify something that doesn’t use software today.

If software powers the world, open source is its beating heart. Today 99% of all software projects consume open source. That is simply incredible. It is a testament to the work that so many have given freely. Everyone that contributes to open source should be proud about how they have helped us all move forward.

With that success comes responsibility. Open source must be something that the world can trust. As open source creation and consumption continues to rise, this problem is becoming increasingly important—and increasingly challenging.

A new approach

Today the security lifecycle is broken:

  • Identifying vulnerabilities is a manual, ad hoc process.
  • Disclosures are often not made responsibly—if they’re made at all.
  • Security vulnerabilities are fixed outside of normal open source workflows, without the support of critical tooling just to avoid premature disclosure.
  • Developers don’t get security alerts for their projects that consume vulnerable software, or if they do, they may be overwhelmed by the number and complexity of issues to investigate; which can consist of both real and false-positives.
  • Updating vulnerable dependencies takes too long or simply doesn’t happen at all.
  • Nothing prevents the mistake that introduced a vulnerability from happening again.

As the home for most of the world’s open source, this is a problem that we at GitHub feel responsible for addressing. But we can’t do it alone. No one can do it alone. Software security is a collective problem, a responsibility that involves producers and consumers of code, open source maintainers, security researchers, and security teams. At GitHub, we want to give the community the tools it needs to secure the software we all depend on.

Ten years ago, GitHub introduced the pull request. For so many of us, it gave us a better way to work together. In the same way the pull request created a standard process for managing contributions, the ecosystem needs better-defined processes for managing vulnerabilities in open source code. This is what we’re setting out to build at GitHub.

The security advisory

A typical security vulnerability workflow involves researchers, maintainers, and developers.

  1. Researchers identify vulnerabilities and disclose them to the maintainers.
  2. Maintainers fix the issue and send an alert to the community.
  3. Developers update to the fixed version and look to prevent a recurrence.

Security advisories cover every step of security, from identification to disclosure and remediation.

We believe this entire workflow needs to be as natural as pull requests are today. We’ve taken steps down that path already, and you’ll see us continue to take more.

Today in GitHub, a security advisory is the entity that tracks a vulnerability from the beginning to the end of this lifecycle. It connects the researcher that found the issue to the maintainer that fixed it and the developers that depend on it.

Security researchers

Security researchers play a critical role in keeping the world’s codebase safe by identifying and disclosing vulnerabilities. As software development has grown, however, the community of security researchers has not, and the ratio of security researchers to developers continues to drop.

It’s critical that these researchers can be as productive as possible. We are incredibly excited to have Semmle join GitHub.

Traditionally, vulnerabilities are discovered by penetration testing, or inspecting code by hand. Semmle scales the work of security researchers by treating code as data. Their code analysis engine—named QL—combines the latest research in compiler optimization with insights in database implementation. It understands the complex data structures inherent in code, and makes analysis available to researchers using a declarative, object-oriented query language.

Just as relational databases make it simple to ask very sophisticated questions about data, Semmle makes it much easier for researchers to identify security vulnerabilities in large code bases quickly. Many vulnerabilities have the same type of coding mistake as their root cause. With Semmle, you can find all variations of a mistake, eradicating a whole class of vulnerabilities. Furthermore, this approach makes Semmle far more effective, finding dramatically more issues and with far fewer false positives.

Security researchers identify vulnerabilities and their variants with a QL query. This query can be shared and run over many codebases, freeing up security researchers to do what they love and do best: hunt for new classes of vulnerability. Because QL is declarative and object-oriented, creating a new analysis is much easier than with traditional code analyzers. Customers frequently find vulnerabilities they couldn’t find with other tools and accomplish tasks that used to take weeks or more in hours.

An important measure of the success of Semmle’s approach is the number of vulnerabilities that have been identified and disclosed through their technology. Today, over 100 CVEs in open source projects have been found using Semmle, including high-profile projects like Apache Struts, Apple’s XNU, the Linux Kernel, Memcached, U-Boot, and VLC. No other code analysis tool has a similar success rate.

We are in the early stages of bringing the Semmle technology to GitHub users. Stay tuned!

After a researcher or developer finds a vulnerability, the next step is to coordinate disclosure with the project maintainer. Simply identifying the person, much less contacting them in a private manner, can be a challenge. Reporting a security vulnerability safely is something that anybody should be able to do for any OSS project. Security policies are a small first step toward helping folks do that on GitHub.

Once a vulnerability is reported for a project, the project’s maintainers can create a security advisory so the researcher, maintainer, and development team can privately coordinate on how best to address the vulnerability.


Maintainers are under incredible pressure. Not only do they have to try to make sure that every release they publish is secure, they also have the responsibility to fix vulnerabilities quickly when they are found. Making their challenge even harder, they often can’t even work on the fix using their normal tools for fear of accidentally disclosing the issue.

Within a security advisory, maintainers can create a private fork as a safe place to collaborate on a fix. In the future, we will make this private fork a fully functional environment in which to work, including private CI using Actions.

Once the maintainers have completed their fix, they will publish patched versions that address the vulnerability, and, critically, a security advisory. Making sure the community knows about vulnerabilities at the right time is one of the most valuable things we can do at GitHub. So often exploits happen using vulnerabilities that have fixes available but just haven’t been picked up by the larger community. Today, for an ever expanding set of languages, GitHub understands what dependencies that project has in the dependency graph.


This allows GitHub to alert all downstream users affected by the vulnerability, both within GitHub and via email—and we’re continuing to optimize the way we communicate these alerts.


GitHub currently issues alerts for advisories that were reported directly on GitHub, as well as vulnerabilities from other sources, such as the National Vulnerability Database, MITRE, and WhiteSource. GitHub hand curates every vulnerability to confirm the impact and affected users before we issue alerts, ensuring users are always getting actionable alerts.

GitHub is now a CVE Numbering Authority

We believe that fast, unfettered movement of vulnerability data is critical to improving software security. This is why we’re excited to share that GitHub has been approved as a CVE Numbering Authority for open source projects. We’ll be able to issue CVEs for security advisories opened on GitHub, allowing for even broader awareness across the industry.


Developers have the all-important job of keeping their projects secure. A huge part of this means keeping their dependencies updated.

We know that alerts aren’t enough. A significant percentage of critical vulnerabilities go unpatched for months—and the risk to an organization from unpatched vulnerabilities grows as the unpatched code is proliferated.

Updating dependencies needs to be as easy as possible. Earlier this year, we acquired Dependabot, and we now provide automatic security fixes natively within GitHub. With automatic security fixes, developers no longer need to manually patch their dependencies: when a vulnerability is found in a dependency, GitHub will automatically issue a pull request on downstream repositories with the information needed to accept the patch.



Developers also want to be able to prevent new vulnerabilities from occurring. In many ways, this is the hardest of the challenges we face. While this will be an area of continued innovation in the industry, there are a couple of things that we are doing now.

GitHub Token Scanning scans public code for secrets from more than 15 providers. GitHub works with providers like Azure and AWS to validate the secret is active and to notify secret owners to safely disable and remediate the exposure. This capability will soon include optional scanning of private code for our community.

Finally, Semmle QL benefits both developers and maintainers. It has a library of thousands of queries, all open source, that have been defined by some of the industry’s best security researchers. These queries can be used to detect vulnerabilities as part of your pull request workflows to prevent vulnerabilities before they are ever released.

Security teams

Developers are busy folk, and we know sometimes things like security vulnerabilities can slip through the cracks. In enterprises, this can expose customers to vulnerabilities, so we provide security, compliance, and open source offices a turnkey way to audit your organization’s open source dependencies for security vulnerabilities with dependency insights.

A safer future for all of us

While the largest open source communities are backed by organizations that have security researchers, the vast majority of projects simply don’t have the tools, expertise, or resources to investigate, address, and propagate security issues.

This is a problem we are committed to help fix. At GitHub, our mission is to build the global platform for developer collaboration—one that all of us can use to secure the world’s software, together.

The post Securing software, together appeared first on The GitHub Blog.

Welcoming Semmle to GitHub 18 Sep 2019, 5:26 pm

Human progress depends on the open source community. One of the biggest issues facing developers today is how to create and consume open source in a secure and trusted way. And at GitHub, we have a unique opportunity and responsibility to provide the tools, best practices, and infrastructure to make software development secure.

Today we’re announcing a big step in securing the open source supply chain: we’re welcoming Semmle to GitHub.

Semmle’s revolutionary semantic code analysis engine allows developers to write queries that identify code patterns in large codebases and search for vulnerabilities and their variants. Semmle is trusted by security teams at Uber, NASA, Microsoft, Google, and has helped find thousands of vulnerabilities in some of the largest codebases in the world, as well as over 100 CVEs in open source projects to date.

Security researchers use Semmle to quickly find vulnerabilities in code with simple declarative queries. These teams then share their queries with the Semmle community to improve the safety of code in other codebases. Software security is a community effort; no single company can find every vulnerability or secure the open source supply chain behind everyone’s code. Semmle’s community-driven approach to identifying and preventing security vulnerabilities is the very best way forward.

To learn more about our approach to developer security, check out a detailed overview of secure development on GitHub from Shanku Niyogi, SVP of Product. The Semmle blog has many videos and examples of Semmle in action, and you can check out your favorite open source projects on Semmle’s

We’re so excited to be joined by the Semmle team and to welcome their world class engineers and security researchers to GitHub. Together, we’ll bring their work to all open source communities and to our customers. As a community of developers, maintainers, and researchers, we can all work together toward more secure software for everyone.

The post Welcoming Semmle to GitHub appeared first on The GitHub Blog.

Dependency graph support is now available for PHP repositories with Composer dependencies 18 Sep 2019, 5:19 pm

The dependency graph powers many important experiences in GitHub, including security alerts, the “used by” counter, dependency insights, and automatic security fixes. We’re also seeing PHP and Composer grow in popularity—PHP is the fourth most popular language on GitHub and Composer is the fourth most starred PHP project. We’ve taken note, and the dependency graph is now rolling out for all PHP repositories with Composer dependencies. In addition to Composer, GitHub supports package managers for other programming languages, including Maven, NPM, Yarn, and Nuget.


You may see security alerts on your repositories as dependency graph support rolls out. When there’s a published vulnerability on any of the Composer dependencies that your project lists in composer.json and composer.lock files, GitHub will send you an alert including email or web notifications, depending on your preferences.

Public and private repositories

If your repository is public, you’ll start receiving these alerts automatically—no need to change anything. If your repository is private or if you disabled the dependency graph on your repository, enable the dependency graph to start receiving alerts.

Multiple private repositories

Organizations with multiple private repositories can also enable the dependency graph across their repositories using a script enabling security alerts and automated security fixes.

Disable alerts on old projects

What if you don’t want to receive alerts on those old PHP projects you wrote years ago? Archive them! Archived repositories send a signal to the rest of the community that they aren’t maintained and don’t receive security alerts.

Automatic security fixes beta

If you’ve opted in to the automatic security fixes beta, you’ll receive pull requests for your vulnerable PHP dependencies when you receive security alerts. Learn more about automatic security fixes.

Enterprise plan subscribers

Organizations using GitHub Enterprise can also start leveraging dependency insights to view information about PHP dependencies. Dependency insights offers a summary of the dependency graph information across all repositories in an organization or across organizations. This makes it easy to identify where you may be using vulnerable dependencies, while providing information about a dependency’s license.

The post Dependency graph support is now available for PHP repositories with Composer dependencies appeared first on The GitHub Blog.

Celebrate seven years of GitHub Education with new features and #MyFirstRepo 17 Sep 2019, 4:00 pm

Your first repository on GitHub is a special one. It’s the beginning of a new chapter for you as a student, aspiring developer, teacher, or a seasoned developer. You continued to add to the story with every line of code. You may have met new friends along the way who also contributed to this story. You were there at the very start of that repository and chronicled its journey to what it is today. You put this story out into the world where others could read it and even add their own chapters. 

Like you, GitHub Education started with a single repository. In many instances, the first maintainer of this repository shared a similar story: They were faced with many questions, roadblocks, ideas, and goals. We looked to the education community for guidance, and soon, the story of our repository began to unfold.

With your help and feedback, we created:

There’s more to come

We’re grateful to celebrate seven years of GitHub Education, but there’s still a great deal of work to be done. The GitHub Education Team is deepening our commitment to the education community with a wave of new offerings:

  • New learning modules for the Campus Advisor Program to prepare teachers to teach with Git, GitHub, and other industry tools in their classroom 
  • The Campus Advisor Professional Development Network, which allows certified Campus Advisors to request support for professional development from GitHub Education
  • Free access to Stack Overflow for Teams for GitHub Campus Program participants
  • New GitHub Student Developer Pack partner offers
  • A new partnership with Hack Club to bring more computer science resources to high schools
  • New GitHub Classroom features like sync-able class rosters from learning management systems for teachers

GitHub Education started with one repository, one maintainer, and many ideas, but we eventually grew because of the community. Happy seven-year anniversary to our students, teachers, alumni, and friends in the future who will be part of our story.

Learn more about GitHub Education

Share your first repository

To celebrate seven years, we want to hear about your first repository. If you’re a verified GitHub Education student or faculty member, share the story of your first GitHub repository for a chance to win a GitHub Education backpack. Post about your first repository on Twitter, mention @GitHubEducation, and include the hashtag #MyFirstRepo by October 15 at midnight PT to enter.

Check out #MyFirstRepo on Twitter

The post Celebrate seven years of GitHub Education with new features and #MyFirstRepo appeared first on The GitHub Blog.

¡Hola! Our help documentation is now available in Spanish 16 Sep 2019, 11:00 pm

Lee este artículo en español

¡Hola! Soy Alexandra y trabajo en el grupo de documentación técnica de GitHub y me encargo de gestionar los proyectos de localización, internacionalización y traducción de la documentación. He trabajado en el área de localización en diferentes empresas durante los últimos 15 años, y soy una experta en globalización de productos y en hacerlos accesibles a comunidades alrededor del mundo. Al haber nacido y crecido en México, soy consciente de los desafíos que implica no hablar inglés, y cómo eso puede limitar nuestras oportunidades y posibilidades. Quiero que GitHub sea el hogar de todos los desarrolladores, sin importar en que parte del mundo vivan y trabajan.

Nos complace anunciar que nuestro sitio con documentación de ayuda,, ahora está disponible en español. Latinoamérica es uno de nuestros mercados de mayor crecimiento y con la incorporación de la documentación en español, esperamos que más personas alrededor del mundo descubran la comunidad y los productos de GitHub. Al contar con soporte en español, anhelamos brindar más oportunidades para los desarrolladores de Latinoamérica y España.

Nuestro nuevo sitio localizado en español incluye documentación para, GitHub Enterprise, GitHub Desktop y GitHub Pages. Puedes acceder a nuestro sitio en español visitando, y seleccionando Español desde el menú desplegable, que se encuentra en la parte superior derecha del sitio web, o visitando

Disponibilidad de las traducciones

Nuestro sitio de ayuda funciona sobre un sistema de integración continua con Crowdin, una herramienta de localización y uno de nuestros socios de GitHub Marketplace. Un sitio web con integración continua nos permite contar siempre con el contenido más actualizado en español o en cualquier otro idioma que esté disponible en GitHub. Es posible que algunos artículos traducidos o que algunas oraciones dentro de un artículo estén en inglés. Eso significa que el contenido se agregó recientemente al sitio web y que actualmente está esperando ser traducido; si encuentras texto que permanece en inglés, vuelve al sitio web en unos días a comprobar si ya está traducido. Siempre estamos traduciendo contenido nuevo para que cuentes con la información más reciente en el idioma que deseas.

Búsqueda en español

Nuestro nuevo sitio ofrece un motor de búsqueda que soporta el español; pruébalo cuando busques algún tema. Para realizar una búsqueda en español, escribe tu criterio de búsqueda en el sitio en español en 

A medida que el mundo está más interconectado, queremos respaldar a nuestra comunidad global de programadores para que puedan desarrollar nuevos productos e innovar orientados al futuro, independientemente del idioma que hablen. Esperamos agregar más idiomas en el futuro así como documentación adicional como Ayúdanos a compartir el nuevo sitio en español en tu comunidad.

Explora nuestra documentación de ayuda en español

Hello! I’m Alexandra and I work on the GitHub documentation team where I help localize and translate our content. I’ve worked in different localization roles for the last 15 years, and I’m passionate about product globalization, as well as making new products accessible to communities around the world. Having been born and raised in Mexico, I’m aware of the challenges of not being able to speak English, and how this can limit your opportunities and prospects. We want GitHub to be home for all developers—no matter where in the world they live and work.

Our documentation site,, is now available in Spanish. With Latin America becoming one of our growing markets, we hope to alleviate some of the challenges of not speaking English and open up opportunities for more developers in Latin America and Spain. 

Our new localized Spanish site includes documentation for, GitHub Enterprise, GitHub Desktop, and GitHub Pages. You can access our Spanish language site by visiting, and then selecting Español from the language selection drop-down menu, located on the top right of the website, or by visiting

Availability of translations

We’re always translating new documentation to provide information in your preferred language. Our help site runs on a continuous integration system with Crowdin, a localization tool and one of our GitHub Marketplace partners. Continuous integration allows us to always publish the latest articles in Spanish or any other GitHub-supported language. You may notice that some sentences within a translated article are in English. This means the content was recently added to the site and is currently in a queue waiting to be translated—if you find text still in English, check back in a few days for the translation.

Search in Spanish

Our site also offers a search engine that supports Spanish. To try it out, type any search topic in the search bar of the Spanish site at

As the world grows more interconnected, we want to support our global community of developers as they build the future of software, regardless of the languages they speak. We expect to add even more languages and more translated sites, like Help us by sharing the new Spanish language site in your community.

Explore our help documentation in Spanish

The post ¡Hola! Our help documentation is now available in Spanish appeared first on The GitHub Blog.

Try GitHub Enterprise Cloud for free 16 Sep 2019, 5:12 pm

Whether you’re a small growing team or leading an enterprise, GitHub Enterprise has everything you need to build and scale. If you’ve been waiting for the right time to take your workflow to the next level and give our cloud-hosted solution for businesses a test drive, the wait is over. GitHub Enterprise Cloud is better than ever, and now your team can try it for free. 

Try Enterprise Cloud for free

What’s included

You’ll have the chance to try Enterprise Cloud for 14 days, including our beta features, with a quick and easy signup process—and no long-term commitment. Here are just a few reasons to give it a try:

Built-in CI/CD

Your Enterprise Cloud trial includes our latest features like GitHub Actions and GitHub Package RegistryGitHub Actions provides built-in CI/CD as well as an ecosystem of community-built workflows to automate your entire software development lifecycle. Build, test, and deploy your projects on any platform or cloud. GitHub Package Registry provides support for JavaScript, RubyGems, Java, NuGet, and Docker. Combine GitHub  Actions with GitHub Package Registry to publish and discover packages and containers—all in one place.

Supercharged security

With Enterprise Cloud, you’ll get industry-standard tools like SAML that make it easier to keep your code safe and data-powered security alerts that proactively find known vulnerabilities in your code. And now with Dependabot, you can automate these fixes and keep your projects secure and up to date by monitoring your dependencies and automatically opening pull requests to fix known vulnerabilities.

Seamless collaboration

Our cloud-hosted solution gives teams the tools to kick up collaboration alongside the world’s largest open source community. Give teams more ways to share code, best practices, and expertise across your organization—while prioritizing security and compliance requirements.

Guaranteed stability 

When your business is growing, you don’t have time to wait for your support tickets to move through a queue that serves millions of other people. With Enterprise Cloud’s 99.95% uptime SLA and dedicated Support Team, you can count on stable access and fast fixes. And if you need even faster response times, our Premium Support offering has you covered 24/7—available for purchase after your trial.

Try it out

Enterprise Cloud extends the flexibility of GitHub with features that minimize administrative challenges and security risks as your projects grow. So you can focus on building your business—and leave the rest to us. With no commitment needed, what are you waiting for?

Start your Enterprise Cloud trial

The post Try GitHub Enterprise Cloud for free appeared first on The GitHub Blog.

GitHub Pages builds now use the Checks API 13 Sep 2019, 4:25 pm

Imagine that you’re updating your GitHub Pages site. You push a commit, and a new build starts. The build fails, and the site isn’t deployed. But you’re not sure how to fix the error until you get an email notification with links to documentation on troubleshooting your build—this how it worked when statuses were the primary way for GitHub Pages to communicate build statuses. When everything built successfully, it was great. When there was an error, it was hard to understand which line of code was the culprit. Now, to ensure everyone has the right details to move forward faster, we’ve integrated the Checks API with GitHub Pages.

On a typical day, we see about 125,000 GitHub Pages builds—and sometimes, you need a little help understanding an error if something goes wrong. Maybe you mistyped something in your _config.yml or have an invalid syntax in a Liquid template. This is a normal part of the process, and these types of errors are exactly why we built the Checks API. Providing our community with the context they need to work through build errors saves them time troubleshooting, debugging, and reaching out to support for help.

What’s new

After a GitHub Pages build is triggered, you can now go to the commit and click on the status indicator to reveal the status of the checks. Selecting Details for a check run will open up the “Checks” interface. There you’ll see a clean user interface showing detailed annotations for specific lines of code and information about the analysis performed in the check run. The builds also indicate when the site has been successfully deployed and the cache has been cleared. Additionally, you’ll have the option to re-run checks in case the build timed out. This provides everyone with a better CI experience, empowering them to discover and fix their GitHub Pages builds with ease.

Click the status indicator next to you commit to view the details of your checks run.

Let us know what you think

We’re rolling out this integration over the next few days—and soon, GitHub Pages users will automatically have their builds run using the Checks API. We’re so excited about this change and hope you are, too. Feel free to reach out on Twitter if you have any feedback about how GitHub Pages and the Checks API are working for you, or check out the product documentation if you have a question.

The post GitHub Pages builds now use the Checks API appeared first on The GitHub Blog.

Global software collaboration in the face of sanctions 13 Sep 2019, 12:00 am

Law and policy profoundly shape software development—including what software is built, how it is used, and who gets to build it. Many policies that impact developers have an international relations aspect, which is both challenging and absolutely critical to understand and navigate. Software collaboration and related communication are global, and GitHub is committed to an inclusive future which every human can help build, and from which every human can benefit.

About sanctions

Sanctions are one international policy area that’s been especially painful for us at GitHub and for the global developer community. Sanctions are complex both in their terms and in their implementation, so we think it’s important to provide some explanation of US sanctions laws, why GitHub is required to take certain steps in accordance with US sanctions laws, and how GitHub is striving to implement these steps in a compliant way but also with minimal impact on the global developer community. In writing about sanctions, our goal is to provide a basic explanation of the topic, along with how it affects both developers—including GitHub—and the global open source community.

Countries may impose sanctions to achieve national security and foreign policy goals, and in response to various international events, such as armed conflicts, human rights issues, or concerns about terrorism, among other reasons. For example, the US imposes broad prohibitions at the country level, which generally prohibit US persons (including US companies) from doing business with a sanctioned country, or anyone in it. The US also imposes comprehensive sanctions against individuals and entities that the government designates on its Specially Designated Nationals and Blocked Persons List.

Complying with sanctions

Sanctions are complex and were originally designed to regulate trade in more traditional goods and services, especially financial products. For companies that provide certain types of digital services, compliance presents novel legal questions and involves some uncertainty.

One approach has been to block access to these digital services from sanctioned countries entirely. For companies taking that blanket approach, developers in sanctioned countries have lost—or never had—access to many services provided by those companies. GitHub approaches this differently. We’re dedicated to both allowing as many developers around the world as possible to participate in the open source community and to following the law. Compliance with US sanctions laws means that we’ve had to restrict access to some of our services for developers in sanctioned countries, including some of the services we ordinarily provide at no cost to individual developers.

At the same time, we’re doing everything we can to keep as much of GitHub available to as many developers as possible. While many of the GitHub services—in particular, private repositories—are currently inaccessible to users in sanctioned countries, developers can still contribute to and use public repositories, and participate in the global open source software community by working on public projects. If a user’s private repository has been restricted, we give them the option to make that repository public so they can still access their contents for personal communication purposes. Importantly, open source projects on GitHub remain freely available to developers virtually everywhere, supporting a global community and minimizing fracturing of the internet along national borders.

Complying with these sanctions isn’t a choice based on what we think about a particular country or the developers in it. Instead, this is GitHub following the law, which is the obligation of any company doing business in the US. We implemented access restrictions for developers we understand to be located or resident in sanctioned countries, and not based on nationality or heritage. If your account has been restricted, it will display a link to an appeal form. If you’ve been flagged in error, please fill out the appeals form to help us fix it quickly.

Sanctions in the future

We believe that preserving access to code and code collaboration promotes the broader objectives of US sanctions laws and the US government’s commitment to supporting the free flow of information worldwide. That means GitHub will continue to advocate for rules and regulatory interpretations that keep source code, open source collaboration, and GitHub available to as many people as possible. We’re working to engage with US regulators regarding the impact of sanctions on GitHub and the global developer community. Our goal is to preserve as much access as possible for developers around the world, including in sanctioned countries.

If you have questions, our trade controls policy and FAQ is the best place to look for current information about trade compliance at GitHub. Like the rest of the policies that govern GitHub, our trade controls policy is open source.

Looking ahead, we’ll continue to closely monitor developments in US sanctions laws and will restore access for restricted users as soon as we’re legally able to do so. We’ll continue to speak—to corporations, to individuals, and to governments—about the value of ensuring that humanity can share information and collaborate around the world to produce positive outcomes. We’ll also continue our work to ensure as much clarity as possible regarding the impact of US sanctions laws on GitHub. We believe sanctions must be narrowly tailored and clear as to precisely what they cover so that software collaboration, research, and development aren’t inadvertently affected by these laws. Protecting software development, and software developers, is the primary goal of GitHub and our Policy Team.

The post Global software collaboration in the face of sanctions appeared first on The GitHub Blog.

How to survive internship applications and interviews: Best practices from Campus Experts 12 Sep 2019, 4:00 pm

In the spring, we talked to four GitHub Campus Experts, John, Marleni, Sourabh and Yosuf, about their experiences as interns. Along with how to have a great internship, they offered their advice on how to help you find, apply, and interview for internships. Here’s what you need to know to have a great summer internship:

Think long-term

Above all, the Campus Experts emphasized the importance of preparation. An internship isn’t just for the summer or a semester, it’s a year-long project that benefits from planning ahead. And for some students, like Sourabh, an internship may be a graduation requirement, which means skimping on finding and preparing for an internship may not be an option.

Yosuf and John told us that, before anything else, it’s important to find out what interests you. They both suggested hackathons as a way to find skills to develop on your own time. John explained, “I switched to computer science after my first hackathon. It gives you a glimpse of what tech companies are doing.” Yosuf added, “A large part of preparing is figuring out what you’re interested in, whatever it may be. Hackathons are great for that.” And when the time comes for your application or an interview, having experiences that point to your interests can help you talk about your skills more comfortably. Yosuf suggested to, “Take an interest and try to practice that. By the time it gets to an interview, it’s much more natural.”

Apply early and often

Everyone stressed the benefit of applying early and widely when it comes to internships. For a summer internship, you might start the application process in the preceding autumn (in other words, right now). 

Sourabh talked about taking advantage of his university’s careers portal to find and apply for roles, while Marleni encouraged using your alumni network. “I go to a very small school. A lot of the time we don’t have the recruiting power of larger universities. Using alumni services really helped me.“ She also stressed the importance of attending events like Grace Hopper, where many women in technology find opportunities and get offers. “It’s a huge difference getting to meet recruiters in person.”

John and Marleni both had a lot to say about the importance of knowing the requirements for internships you’re going after, like getting transcripts, letters of recommendation, and other documents to complete the application process. But they also said you should reach for opportunities even if you don’t meet every single requirement of a position. John explained, “That’s rejecting yourself. Let the person on the other side reject you. And what happens if they don’t? Then you’ll have an amazing opportunity.“ Marleni added, “Don’t count yourself out for anything, especially if you are younger or don’t have the experience. Because there’s a chance you’ll get it. And even if you don’t, they might consider you for another role.”

Every application is unique

Employers use different strategies to find their ideal candidates for every role. When you apply for internships, you’ll find that no two applications or interviews are the same, which is why it’s a winning strategy to pay attention to the process and be prepared.

Whiteboard coding is often a source of anxiety for job applicants, but the Campus Experts stressed that coding by the seat of your pants isn’t the only way your application can be judged. Yosuf said that he didn’t have an in-person interview to get his internship at CERN. “They put a very large emphasis on the actual application.” Instead of relying on connecting with an interviewer directly, he had to shine through in his CV and responses to their questions”

John, Marleni, and Sourabh noted that interviewers are interested in more than just technical abilities. They all encountered behavioral interview questions that explored their interests and experiences more than their raw programming talent. As Marleni put it, it’s a process to find “the best fit” for a position, not the best coder.

The dreaded whiteboard

Testing coding skills isn’t the only way potential interns are evaluated, but it’s often a part of the process. It makes sense that the coding interview is a source of anxiety, but the Campus Experts had reassuring advice. Interviewing well is a skill like any other—you can get better over time with enough practice.

Sourabh said that your first interviews will be the most challenging. “The scariest time is when you’ve never had any interviews before. But after the first few, I started to see the patterns.” Yosuf pointed out that not every interview will go well, but you can learn from each one. “The interview experience itself is quite valuable because it prepares you for the next interview.”

Interview resources

Rather than going into an interview unprepared, take the time to practice. We polled all Campus Experts and they shared their favorite resources for coding interview prep:

The GitHub community has your back too. Check out the range of GitHub topics on interviewing, such as interview or coding-interview for examples. Or try a search for “interview” and your favorite programming language for more examples to practice with.

Good luck with your internship!

Companies are already advertising internship positions for next summer. But it’s never too early or late to build up your skills, fill out applications, and practice for interviews. Want to join our summer internship program? Sign up to be the first to know when applications open.

Learn more about Campus Experts

The post How to survive internship applications and interviews: Best practices from Campus Experts appeared first on The GitHub Blog.

Proxying packages with GitHub Package Registry and other updates 11 Sep 2019, 5:00 pm

It’s been a few months since we announced GitHub Package Registry, a package management service that makes it easy to publish public or private packages next to your source code. As we’ve talked to the community, we’ve heard a few common themes. We’ve heard that ease of configuration is important, from standardizing permissions across repositories and packages to simplifying the configuration needed to use the registry from your command line. You also let us know that it doesn’t always make sense to create a release every time you publish a package. And, centralizing all of your package dependencies in one place should be a standard feature for a package manager. 

We listened to your feedback, and we’re excited to announce proxy support for the primary npm registry. We also removed the feature that automatically creates releases when you publish a package.

Introducing proxy support for

The proxy enables you to use GitHub Package Registry as the source of your organization’s npm packages and the proxied source of packages from npm. Try it out—just change the .npmrc file in your project directory (replacing OWNER with your GitHub organization or username):

Old format New format, with proxy support
@OWNER:registry= registry=

This change tells npm to send all package requests to GitHub Package Registry, which will then serve any request for a package in your account (any package starting with @OWNER), just like it does today. It will also proxy requests for any other package to npm, so you can use packages like express or @babel/core.

We imagine this feature growing in several ways:

  • Add support for other npm sources so you can use packages from places other than
  • Broaden proxy support for other package types (Maven, NuGet, and Ruby)
  • Build a permanent cache on top of the proxy service to help with protection from outages

There are many possibilities with what we can do, and we’d love your feedback about what the next improvements should be. 

Take the survey

No more automatic release creation

Many customers expressed that automatically creating a release for every package published was unexpected and undesirable, and that it led to conflicts for repositories that were managing their releases closely already. As of today, publishing a package will no longer create an accompanying release. 

If you’d like to bring this functionality back, you can create a GitHub Action that triggers on the RegistryPackageEvent from GitHub Package Registry.

Using packages in Actions

We’re continuing to bring Actions and GitHub Package Registry closer together, starting with removing the need to use personal access tokens to access packages from Actions. Instead, you can use GITHUB_TOKEN when publishing or installing Maven or npm packages in a GitHub Actions workflow. We’re also introducing support for NuGet packages.

Tell us more and join the beta

As we prepare to make GitHub Package Registry generally available at GitHub Universe later this year, we want to continue to learn about your needs. Share your thoughts in our survey to get expedited access to the GitHub Package Registry beta. 

Fill out the GitHub Package Registry survey

The post Proxying packages with GitHub Package Registry and other updates appeared first on The GitHub Blog.

This page processed in 0.67 seconds.

Leave a Reply

Your email address will not be published. Required fields are marked *