Tell HN: GitHub no longer supporting unauthenticated `git://`
Blog post from a few months ago, but it seems to have gone into effect today.
https://github.blog/2021-09-01-improving-git-protocol-securi...
https://github.blog/2021-09-01-improving-git-protocol-securi...
(I'm the product manager for Git Systems at GitHub.)
- People who aren't using the old methods can turn them off now and leave them off, benefiting from the new security change sooner.
- People who need to fix something can temporarily repair their workflow at the time of their choosing.
- People who need more than 24 hours to fix their workflow can re-disable the old methods to test that they are now good, at a time of their leisure, between today and March.
Well, feature removals do. Deprecations are just declaring that a feature should not be used and either will or may be removed in the future, which causes no operational problems (and in fact is done specifically to help avoid the operational problems of feature removals.)
This was announced long ago. Though have to admit I didn’t see it back then myself.
Because the next brownout is permanent - and that will be an even bigger PITA.
I think it's extraordinarily powerful to have these brownouts for organizations that don't make the change when they should have (which was last year).
The point of the brown out is to help people find cases where they’ve missed this. So “opt out by doing it beforehand” isn’t a viable solution.
The last brownout was a quarter ago. A lot of new things can get introduced in that time that still do it wrong.
Seems like very short-sighted thinking.
The idea is to make brownouts increasingly painful - just letting them be a short period of time, or let people "Opt. Out" doesn't service the purpose here - which is to make it absolutely clear that the service is going away.
more like a blackout.
Brownouts need to be a PITA otherwise people are too likely to miss them or write them off as transient errors.
> I imagine it would be much more technical effort, but a way for us to opt certain repos out of a brownout would be really nice
That's not a bad idea, though.
(Although I'm not an active git/github user, so maybe there's an even more more obvious place a naive user having issues would go to figure out what their problem is. Hopefully there's a helpful commandline error explaining the situation.)
Does anyone know exactly when the brownout will end? I can't find this information anywhere.
E: Some old blog posts on other brownouts seem to suggest 1400 UTC. I still haven't found anything definitive for what's happening now.
In this context it's referring to a transitory period where a feature is in a state of flux and may only partially work.
Comes from terminology used for the electric grid, where a brownout is a milder form of a blackout. Instead of electricity being entirely shut off and everything goes "black," the voltage drops and lights dim, i.e. go "brown."
Other than the blog post that doesn't appear in the changelog RSS, how were we supposed to be made aware of this breaking change?
> Finally, we have the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create a git-daemon-export-ok file — the daemon won’t serve a repository without that file in it — but, other than that, there is no security. Either the Git repository is available for everyone to clone, or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access but, given the lack of authentication, anyone on the internet who finds your project’s URL could push to that project. Suffice it to say that this is rare.
Not really a practical answer, as your SSH client doesn't (and shouldn't) offer this, but of course the rest of the SSH protocol just relies on a negotiated arbitrary encryption for moving data between client and server which is transparent to it, you can drop in different algorithms (on most PCs today AES will be the best option because it is hardware accelerated, on cheaper or lower power hardware ChaCha20 may be much better). So, it is technically possible to have a NO-OP encryption layer but just a bad idea.
SSHv2 negotiates this stuff up front, before anybody authenticates anywhere. Key Agreement protocols like Diffie-Hellman allow two parties to agree over the network on keys and encrypt all their data even though they don't yet know who the other party is, and in SSH the encryption protocols just have string names like chacha20-poly1305@openssh.com so you could invent useless-empty@example.com and if anybody wants to agree to use that the consequences are on them.
Not just technically possible - it actually exists. There is a NONE cipher that is part of the HPN-SSH patches, etc.:
https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/
"The NONE cipher switch disables data encryption AFTER you have been authenticated or logged into the remote host. This can significantly reduce the load on the CPUs of both machines and may improve performance even more. Its important to remember that the initial authentication process is still fully encrypted."
If we're sending data over a private point-to-point link we always consider the NONE cipher ... especially if the underlying data was created by borg or restic anyway ...
If you've insisted on building something that insists on using git:// this way, you can proxy it to the safer supported system seamlessly, since you had no way to know before it was correct and you'll have no way to know if the proxy worked either. Somebody might already make a tool to do that, if not you could roll your own.
git config --global url."https://".insteadOf git://
There are versions of that config line more specific to individual hosts if you didn't want to blanked cover every git host, but it's probably a good idea at this point to instead ask those other hosts if they would consider adding https:// support.
This was true in the past, but the newer "smart" http protocol has content negotiation similar to the git and ssh protocols.
Requiring encryption might be okay, but requiring CA based TLS is not okay. It is another strong force of centralization and shortly thereafter, control.
http is fine. git:// is fine. TLS CA based git and https are great. But CA TLS only to "fix" the problem introduces more security problems than it fixes.
> POSSE is an abbreviation for Publish (on your) Own Site, Syndicate Elsewhere, the practice of posting content on your own site first, then publishing copies or sharing links to third parties (like social media silos) with original post links to provide viewers a path to directly interacting with your content.
...quite yet. Because that's the third 'E' in the strategy, and they're not quite finished with the second one.
CA-based TLS is a requirement that a client can enforce on the servers, not viceversa (except for client certificates which are obviously not the case here).
When a server (Github in this case) chooses to acquire a CA-based TLS, the client isn't forced to depend on the CA in any way - it can even choose not to verify the certificate authenticity.
If the official git implementation started requiring TLS, thus forcing free private git servers (including your personal selfhosted gitea or whatever) to centralize under a recognized root CA, then your comment would make sense.
Is there some other automated system to become aware of changes like this, other than stumbling upon a HN post?
Edit: Also looking here https://github.blog/changelog/ I don't see a related notification. I'm probably missing it though because there seems to be a lot of noise.
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-securi...
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
Using unauthenticated transports for code is borderline malicious.
To some degree, this must be crushing the value of the service.
If ever there was a crying need for setup wizards, configuration audit helpers, and clear error messages, this would be it.
On one hand I can clearly see how git-like history and version control could help in so many areas beyond tech. On the other hand, I can see that's never gonna happen with the barriers to entry we see today.
The Github team should talk to the Rust team about error messages and helpful diagnostics.
Also however GitHub is not able to have the clean slate cargo gets. If I make a new repo, GitHub suggests I populate it with many good things, license info, a README document, and so on... but of course I can't because it's actually just somewhere to push my existing local git repo and if it's not empty that would cause a conflict.
I'm referring to what's required to make a local git repo interoperate with Github.
Either via the command line, or with an editor plugin, or an app. Including the Github desktop app.
That's a nightmare.
2. read the text in front of you:
git remote add origin git@github.com:yourusername/repositoryname.git
git branch -M main
git push -u origin maina) Hasn't set up an SSH key before b) Hasn't used github before
It's more of a hassle now than it was 5 years ago
I've been authenticating with Github with SSH for 10 years - as in the creation date for my SSH key on Github is 10 years old. The process is exactly the same.
Now I understand if your password everywhere is just pass1234 that's easier but, trouble is that means you don't have any actual security. People whose password isn't obvious are clearly better off with keys.
Everywhere I have worked that has been done with passwords so that probably illustrates many of the differences too. One job had required password changes every 90 days so we kept them on the Wiki. For many, passwords are just a required annoyance.
Try it with a fresh laptop: nothing pre-configured. Show someone new how you set up, from scratch.
You're gonna be shocked.
From there, it's as simple as telling the .ssh/config file to use the key from your Yubikey and you can use the same config file on any machine you have OpenSSH.
[core] sshCommand = C:/utils/OpenSSH-Win64/ssh.exe
For GPG, the only things I've done is to use gpg-agent and set up a passthrough for gpg-agent to WSL2 for both OpenSSH and GPG via https://github.com/BlackReloaded/wsl2-ssh-pageant/ since I do development both natively on Windows and via WSL2.
Correct, hopefully Microsoft will provide an updated SSH client soon. It only requires recompiling OpenSSH with the correct flags.
Alternatively, use these build instruction for openssh with FIDO for windows:
https://gist.github.com/martelletto/6a7cf806c6433ac9ce71d66a...
> Using either the PKCS#11 support or the gpg applet requires some extra piece of software
For those wanting to do that, here are some ways:
Using a premade dll:
https://github-wiki-see.page/m/mooltipass/minible/wiki/Setti...
Or with a middleware:
https://github.com/mgbowen/windows-fido-bridge
Using the Hello API:
https://github.com/tavrez/openssh-sk-winhello
Given how many people came with their own ways, I believe there's enough demand for Microsoft to fix that.
I checked when Microsoft-owned GitHub announced full Fido support, but I’ve stopped holding my breath.
(Disclosure, two of the core maintainers of GCM are GitHub employees, though GCM's goal is to work well with any Git host.)
If you have multiple work stations, do you have a method to keep your secrets synched?
Sorry about all the questions! I appreciate any insight you might have on this though.
But more generally, in shell usage: On Unix machines: direnv https://direnv.net/ (It doesn't support powershell; but I see there are scripts for powershell inspired by this). -- Just be very certain these won't get committed into the repo if you're going to put secrets in them.
I think it's preferable to have different secrets for different machines. (e.g. different SSH keys, or different AWS IAM users - which can each assume a shared role if that's easier to manage).
If you want to sync secrets, one easy way is to use a password database, and then use Dropbox whatever equivalent solution. Another way would be to use e.g. PGP keys. (The public key of a PGP key can be shared between machines, and can be used to encrypt contents for that machine).
If I have multiple machines, I manually sync them since that's usually the easiest way to manage it as secrets in my experience don't change enough to warrant syncing them.
[1] https://www.passwordstore.org/ [2] https://github.com/languitar/pass-git-helper
A couple years ago it was harder, but I've done this from scratch on my machines and others' several times over the last few months and it's always easy.
As bad as it is, it’s still better than every other source control I’ve used (vss, clearcase, perforce, cvs, subversion, tfs, mercurial) and their services.
Any attempts to make it easier will likely make it as crappy as stuff like azure devops or other Microsoft source products.
That being said, good error messages would be great. I feel like an idiot whenever someone onboards and gets stuck and I try to remember how I set up my environment however long ago.
(We also set most up with code signing because why not? They think it's cool because we have green checkboxes everywhere, and they get to learn a bit of cryptography too)
My GitHub setup process for myself and new hires hasn't changed in 10 years. I'm a bit flabbergasted at what the difficulty could be.
1. Generate a private/public key pair with openssl
2. Add it to your Github account
3. Done
I believe openssl still even comes standard on mac so you don't even need to install anything.
1) Setup ssh keys
2) Create GitHub account
3) Push public key to GitHub
4) Setup username/email
5) Setup org. permissions on repos
Done..?
For an experienced developer, nothing. But for a beginner, two or three of those steps will be very confusing.
At least that was the case with github for windows last I used it a few years ago.
* ~~Force~~ Encourage people to have github accounts
* Make using plain git more difficult (auth tokens, deprecating passwords, etc) while encouraging people to use the github cli tool
Given microsoft's history of "embrace, extend, extinguish" I have a hard time seeing these changes as anything other than an attack on git as an open ecosystem.
Forcing automation to use per-service authentication tokens in the form of distinct SSH keys or access tokens allows you to
* limit the scope of the token when it gets leaked * Using a password gives you full control over a GitHub account, a SSH key or token much less so * verify which credentials are still actively used * deactivate & replace tokens on a more fine-grained level if one should get leaked
The change in question does not. It only requires that you clone over SSH or HTTPS, not over git://. I don't see why anyone would want to use the latter today.
Given how trivial it is to self-host your own Git repositories on any random Unix box, I am not worried about GitHub attempting lock-in even if they tried.
I've never otherwise used `git://`, and I simply changed them all to `https://`, but I suspect it's mostly that sort of thing that'll bite people - something suddenly stopped working because something else made that decision, and maybe it's buried in a dependency used in CI, and a python library for running git operations, so you can't even find it by grepping, etc.
So while mine especially wasn't hard to fix, I just thought it might be a helpful PSA for people to keep in mind and maybe remember if something goes wrong.
Oh, it was - I'm sure there's a lot of people who are being bitten by this, and nothing I said above should be seen as saying that your post was not useful. :)
git config --global url."https://".insteadOf git:// Host github.com
Hostname github.com
User git
IdentitiesOnly yes
IdentityFile ~/.ssh/github-id_rsa
https://superuser.com/questions/232373/how-to-tell-git-which...
So now when using plain git the choices are to have every action tracked, or to go through a very annoying process involving randomly generated keys.
Not that they couldn't guess that information based on IP address (presuming you're not behind a university NAT or something), but removing password auth does seem like a pretty clear attempt at gathering more user data.
EDIT: this alias has a bug that means it doesn't work as intended, see below, don't use it
If you're that worried, I threw this shitty Bash function together in five minutes just now; stick this in your bashrc and then `anongit ...` instead of `git`:
anongit () {
mkdir -p ~/.random-ssh-keys
KEYNAME=$(openssl rand -hex 12)
KEYFILE=~/.random-ssh-keys/$KEYNAME
ssh-keygen -q -C $KEYNAME -N "" -f $KEYFILE
GIT_SSH_COMMAND="ssh -i $KEYFILE" git "$@"
}
...or you could clone over HTTPS instead :)
GIT_SSH_COMMAND="ssh -i $KEYFILE -o IdentitiesOnly=yes" git "$@"
Oh well. There's still HTTPS!
You have been able to clone over https since day 1 of Github and still can:
git clone https://github.com/user/repositoryI don't know anyone who would advocate using the raw git: protocol without ssh. Setting up an ssh key is not a conspiracy to make it more difficult. Using ssh is simply how it's done.
I'm not a fan of the github app or github cli, I prefer the standard tools. However, calling this "embrace, extend, extinguish" is weird.
But it does require having an account or public key on the server. https does not require having an account, but the http transport protocol is less efficient compared to the native git protocol. If git supported a protocol like gits where it could establish a TLS connection to the server and then use the git protocol for fetch or push, that would be ideal.
It's a bit of a hassle, but I suppose you could always create a public read-only account with a 'private' ssh key made available in the readme.
I work a lot of public repos. I want anonymous reads and clones to be super easy on my users.
I don’t like forcing people to log in just to read. I don’t care about encryption as the integrity of anonymous clones isn’t something I suspect will be abused.
There’s a large set of “I don’t care” style projects where I’m just looking to grab a copy. So even if my ISP (or some nefarious jerk on the same WiFi) could MITM, I don’t care. Plus, I’m not aware of any attacks like this because of the whole git checksum thing it’s harder than injecting into http traffic.
For stuff I care about, I log in.
(it could also reduce encryption and decryption load at both endpoints, and if you have other means to enforce content integrity then the channel itself does not have to been encrypted)
I switched from git:// to https:// and it worked fine. I didn't need to authenticate. So there's no forcing to have accounts going on here at all, as far as I can see.
Not yet. That's the whole point.
It's past the time to move to distributed wikis and issues trackers (perhaps even a Git-based one, like bugs everywhere) so migration will be easier when Microsoft stops baiting and starts switching.
And what do you believe needs to happen for MS to switch into “switch” mode? This change isn’t making people more dependent on GH, the number of accounts is probably growing slower than in the past because almost everyone has an account… What’s the piece missing for them to turn to the dark side?
I think I’ll wait.