Announcements - page 4

New improvements and best practices for account security and recoverability

Strong authentication credentials are critical to preventing malicious access to your account. Everyone on GitHub has a password, so a strong password is an excellent starting point. And, for even stronger assurances, we highly encourage users to enable two-factor authentication (2FA). We’re introducing two new features to help you balance the security, usability, and recoverability of your accounts.

Enforcing stronger passwords

Common password advice is to use a long and unique password for each website you have an account with. It’s challenging to remember a strong and unique password for each website without either using a password manager or using a trivially discovered theme. As a result, password reuse is extremely prevalent. Regardless of the strength of a password, a single breach can nullify its security when used elsewhere.

Several years ago, security researcher Troy Hunt sought to tackle the compromised passwords problem with his project. While Troy hosts a service that people and services can use to check for compromised passwords, he also generously made the approximately 517 million record dataset available for download. Using this data, GitHub created an internal version of this service so that we can validate whether a user’s password has been found in any publicly available sets of breach data.

compromised password banner

Starting today, people using compromised passwords will be prompted to select a different password during login, registration, or when updating their password. Don’t worry, your password is protected by the password hashing function bcrypt in our database. We only verify whether your password has been compromised when you provide it to us.

Two-factor authentication checkup

Using two-factor authentication is a best practice and can help protect you even when low quality or compromised passwords are used. However, two-factor authentication can be a double-edged sword. Two-factor authentication ensures that access to a single factor, such as your password or email address where a password reset can be sent, is not sufficient to access an account. But, if you lose access to your two-factor credentials, it can lead to losing access to your account.

compromised password banner

If you have two-factor authentication enabled, GitHub will now periodically remind you to review your 2FA setup and recovery options. We highly recommend using a 2FA authenticator application that supports cloud backups in the event your phone is lost, stolen, or falls in the ocean.

These new account security enhancements will help improve the security of your account. We hope you will take this opportunity to review the security of your account. Balancing security, usability, and recoverability is a personal decision.

  1. Update your password to a long, unique value that is generated by a password manager. Consider a cloud-synchronized password manager.
  2. Use two-factor authentication. Using a TOTP application is more secure than using SMS to deliver codes, but has a higher chance of irrecoverable loss leading to account lockout. Consider a cloud-synchronized application that supports securely backing up your two-factor credentials.
  3. Ensure you have a method of recovering your account if you lose access to your two-factor device. Having a hardware U2F key is a secure option. Also, be sure to store your two-factor backup codes somewhere secure like a password manager or a secure physical location. Consider linking your account to Facebook via Recover Accounts Elsewhere.
  4. Update your primary email address if necessary and determine if a backup email address is desirable. These settings will determine which email address(es) are allowed to perform a password reset.
  5. Review other GitHub credentials. While we remove SSH keys, deploy keys, OAuth authorizations, and personal access tokens that have not been used in a year, it’s always a good idea to manually review them periodically.
  6. Consider signing up for HaveIBeenPwned notifications. You do not need to provide a password.

If you haven’t already set up two-factor authentication on your GitHub account, visit your account settings and click on the “Security” tab.

Announcing GitHub Desktop 1.3

The latest version of our Electron-based GitHub Desktop app has just launched. With the GitHub Desktop 1.3 release, you’ll be notified when your branch diverges from your repository’s default branch.

We’ve found that one of the easiest ways to prevent really complicated merge conflicts is to merge early and often. But if you’re working on a branch, you shouldn’t have to lose your focus just to periodically check if there are updates on the master branch. You’ll now be notified about changes on your default branch that are not in your current branch, and hopefully prevent merge conflicts from getting unwieldy:

Notification screenshot

This release also enables you to more easily keep up with changes across your repositories. You’ll now be able to see which repositories have had recent activity, uncommitted changes, and unpushed changes without having to click into each one:

Repository list screenshot

Try GitHub Desktop

Git LFS 2.5.0 is now available

A new version of Git LFS, the open-source Git extension for versioning large files, is now available. Git LFS v2.5.0 comes with three new migration modes, a handful of bug fixes, and more.

Download Git LFS v2.5.0

New migration modes

With v2.5.0, you can use the git lfs migrate command in a few new ways.

Sometimes repositories can get into a broken state when large files that should have been committed with Git LFS aren’t. If your file is over 100 MB, you won’t be able to push to GitHub, and your history will require rewriting with git lfs migrate import. If you have a file smaller than 100 MB, you can use git lfs migrate import --no-rewrite to create new commits that move the file to Git LFS, allowing you to repair the state of your repository more easily than ever.

If you have committed a handful of files that should have been stored with Git LFS, but aren’t, you can let Git LFS determine the affected files for you by running git lfs migrate import --fixup. The --fixup flag automatically reads .gitattributes file(s) in your repository, and converts Git objects that should be stored with Git LFS automatically:

In the following example, notice how our .gitattributes file says that *.png’s should be tracked using Git LFS, but we added mona.png without Git LFS:

$ cat .gitattributes
*.png filter=lfs diff=lfs merge=lfs -text

$ git cat-file -p :mona.png | file -s
/dev/stdin: PNG image data, 896 x 896, 8-bit/color RGBA, non-interlaced

We can easily fix this without having to tell Git LFS which files to start tracking:

$ git lfs migrate import --fixup
migrate: Fetching remote refs: ..., done
migrate: Sorting commits: ..., done
migrate: Rewriting commits: 100% (2/2), done
  master        1002728154804338fe645976ad8b7258b0be0810 -> 076e2bfe114df5575b1130f694c18d1b26c86b86
migrate: Updating refs: ..., done
migrate: checkout: ..., done

$ git cat-file -p :mona.png
oid sha256:49afbfc61b10df78377f8f7dac774158e1a0197740e160ea3572d9839c61ac04
size 106277

Now mona.png is stored correctly using Git LFS!

Lastly, if you want to stop using Git LFS and export your large objects, you can use git lfs migrate export. It accepts the same arguments as git lfs migrate import, and easily allows you to take files out of Git LFS.

Developer ergonomics

We have updated several of the scripts and programs used to develop and hack on Git LFS to feel more familiar to open source contributors. The test suite now outputs results using the TAP format, enabling it to be run with prove. Similarly, the project can now be built using a Makefile, which should feel more familiar to developers comfortable working with Git.

Additional updates

You’ll see a handful of other new features and bug fixes in v2.5.0 like improved support for object alternates, correct git lfs status output from subdirectories, and more.

For instructions on configuring Git LFS, refer to this article.

Download Git LFS v2.5.0

Simplify your CI process with GitHub and Google Cloud Build

Simplify your CI process with GitHub and Google Cloud Build

Developers use more than one kind of tool to build software. With the flexibility to integrate exactly the right tools for the job, your team can work productively, however you work best. And when software development is accessible, intelligent, and open, you can spend less time calibrating your tool chain and more time focusing on the work that matters most.

Today, we’re simplifying an important part of your workflow: Continuous Integration (CI). We’re excited to be partnering with Google to bring Google Cloud Build to GitHub. Cloud Build helps you create fast, consistent, reliable builds across all languages. With this new integration, you can easily set up CI through Cloud Build and automate builds and tests as part of your GitHub workflow.

“The release of Cloud Build on GitHub Marketplace is the first step in an exciting partnership. Bringing our fully-managed continuous integration to the GitHub platform will provide fast, frictionless, and convenient CI for any repository on GitHub. Google Cloud and GitHub share a vision for developer productivity and we look forward to continuing to build on this partnership.” — Melody Meckfessel, Vice President of Engineering at Google Cloud

Get smart recommendations

GitHub will detect Dockerfiles in the root of a repository and automatically suggest you use a CI tool like Cloud Build from GitHub Marketplace if one isn’t already set up. These smart recommendations will be rolling out to everyone in the coming months.

Recommender view

Reduce context switching

Cloud Build uses the new Checks API, a better way to get feedback from integrations on your code. Once a build is complete, you can see rich status reports, annotated code, and detailed information—all without leaving GitHub.

Checks UI

Learn more about the Google Cloud Build integration

From large businesses to open source projects, every team has their own approach to CI. We built GitHub to support yours. And we’ll keep working with our partners to create an open platform, where your team can use the tools they need to stay productive and do their best work on GitHub.

Interested in building on our platform? Contact the Marketplace team to learn more.



GitHub Universe logo

GitHub Universe

October 16-17 in San Francisco
Get tickets today

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more