GitHub Blog

It depends on how you found out what the new key value is. By the sounds of your description, you're fine. But in principle there's more than one way people could proceed from here.

If you read the blog post on a verified domain and saw the new key and updated manually, or you deleted the known key and verified the key fingerprint when it warned you about an unknown key, you should be good to go. Here, you trust the people who issue TLS certificates and you trust github to be in control of their domain name, so you can be reasonably confident that the key they advertised on their website is the correct key. If your internet connection was compromised, you would have got an error message when you connected to https://github.blog (because they wouldn't have a certificate from a trusted certificate issuer) or when you connected to the git server (because they wouldn't have the key you just trusted).

If you saw the blog post and then removed the old key and told ssh to save the new key it's receiving without checking it matches the value on the webpage, you might have a problem. The connection to github's ssl could have been compromised, and if you just accepted whatever it told you, you have no trusted intermediate to verify that the key is trustworthy. All you know is that each time you connect to github's server hereafter, you're either connecting to a server with the same key (no error), or you're connecting to one that doesn't have the same key (error message). But…

> Was there some notification of this change sent directly to all github users? I checked email and didn't find any references to the change from github.

Same here. No notification email as far as I can find. (Through this might depend on your notification settings? I have mine set to the minimal.)

>Is there some other automated system to become aware of changes like this, other than stumbling upon a HN post?

Github offer the web changelog, their RSS changelog, and the Twitter account @GHchangelog. These three all relay the same information, and ironically all three missed announcing this important change. Instead they posted a blog post[0] which was not linked at all by the changelogs.

So to answer your question: you need to follow all updates on both https://github.blog/changelog AND https://github.blog.

[0] https://github.blog/2021-09-01-improving-git-protocol-security-github/

I'd rephrase and simplify this article a bit.

`git switch` and `git restore` are better alternatives to the `git checkout` command, as they have a lower cognitive overhead and fewer footguns to avoid. Although these commands are marked in the documentation as experimental, they work extremely well in practice. Experimental in this sense means that these may gain or lose behavior over time, not that these commands are unstable for use. As a community, we should use `switch` and `restore` commands rather than `checkout` when documenting / teaching git so that newer users start with a greater ability to reason about how the commands affect their workflow.

For more about the introduction of these commands and the details of the above see https://github.blog/open-source/git/highlights-from-git-2-23/#experimental-alternatives-for-git-checkout

There's a longer thread here: https://news.ycombinator.com/item?id=42453341

I don't think anyone has directly answered your question, but it might be worth browsing or re-asking there.

I also haven't tried Copilot yet but looking at the free plan announcement it seems like it likely depends on how much you're doing as a hobby coder.

"Now automatically integrated into VS Code, all of you have access to 2,000 code completions and 50 chat messages per month, simply by signing in with your personal GitHub account. Or by creating a new one. And just last week, we passed the mark of 150M developers on GitHub."

https://github.blog/news-insights/product-news/github-copilot-in-vscode-free/

They also mention free unlimited access to Copilot Pro for open source maintainers, students, and educators if you qualify for any of those.

More information here (https://github.blog/open-source/git/git-security-vulnerabilities-announced-6/) on the new CVE:

> When reading a configuration value, Git will strip any trailing carriage return (CR) and line feed (LF) characters. When writing a configuration value, however, Git does not quote trailing CR characters, causing them to be lost when they are read later on. When initializing a submodule whose path contains a trailing CR character, the stripped path is used, causing the submodule to be checked out in the wrong place.

> If a symlink already exists between the stripped path and the submodule’s hooks directory, an attacker can execute arbitrary code through the submodule’s post-checkout hook.

Along with a bunch of other git CVEs that are worth a look.

I think you're probably thinking of Copilot Workspace (<https://github.blog/news-insights/product-news/github-copilot-workspace/>).

Copilot Workspace could take a task, implement it and create a PR - but it had a linear, highly structured flow, and wasn't deeply integrated into the GitHub tools that developers already use like issues and PRs.

With Copilot coding agent, we're taking all of the great work on Copilot Workspace, and all the learnings and feedback from that project, and integrating it more deeply into GitHub and really leveraging the capabilities of 2025's models, which allow the agent to be more fluid, asynchronous and autonomous.

(Source: I'm the product lead for Copilot coding agent.)