Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: GitHub no longer supporting unauthenticated `git://`

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#101

Post by ad700x »

akomtu wrote: post #99
vtbassmatt wrote: post #14

Today we're in a 24-hour brownout period to help folks find places they might have forgotten which rely on unencrypted git:// protocol. The date where this will go away permanently is still March 15, 2022. (I'm the product manager for Git Systems at GitHub.)

Sorry to digress, but what is brownout? First time I see this word.

Usually 'brownout' refers to a situation where an electrical grid is failing to provide sufficient power but is still providing some. It's not quite a blackout, but its also not functioning properly.

In this context it's referring to a transitory period where a feature is in a state of flux and may only partially work.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#102

Post by dwohnitmok »

akomtu wrote: post #99
vtbassmatt wrote: post #14

Today we're in a 24-hour brownout period to help folks find places they might have forgotten which rely on unencrypted git:// protocol. The date where this will go away permanently is still March 15, 2022. (I'm the product manager for Git Systems at GitHub.)

Sorry to digress, but what is brownout? First time I see this word.

Degrading a service/feature or having intermittent failures rather than just immediately knocking a service/feature offline. In this case, intentionally induced and used as a strong nudge to downstream users to stop using this particular feature.

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."

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#103

Post by ziml77 »

bin_bash wrote: post #18
otherjason wrote: post #4

Earlier quoted context omitted.

No. From https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco... : > 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’…

I was also under the incorrect impression that git:// was just an alias for ssh. It's amazing how long you can use something and still not understand how it works.

I thought the same thing! I didn't expect git to have a way to communicate unauthenticated and unencrypted built-in.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#104

Post by [deleted] »

akomtu wrote: post #99
vtbassmatt wrote: post #14

Today we're in a 24-hour brownout period to help folks find places they might have forgotten which rely on unencrypted git:// protocol. The date where this will go away permanently is still March 15, 2022. (I'm the product manager for Git Systems at GitHub.)

Sorry to digress, but what is brownout? First time I see this word.

[deleted]

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#107

Post by superkuh »

judge2020 wrote: post #2

git:// is not just unauthenticated, but unencrypted on the wire. They want you to use https:// for unauthenticated clones to at least prevent MITMs.

Like most crimes, the biggest and most common dangers come from the people/software you already know. It's going to be a company's profit incentive or a lone dev's hissy fit expressed through softare you implicitly trust that gets you. Unencrypted internet transfers have worked and will continue to work for a very long time with very few problems for the vast majority of people.

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.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#108

Post by purkka »

superkuh wrote: post #107
judge2020 wrote: post #2

git:// is not just unauthenticated, but unencrypted on the wire. They want you to use https:// for unauthenticated clones to at least prevent MITMs.

Like most crimes, the biggest and most common dangers come from the people/software you already know. It's going to be a company's profit incentive or a lone dev's hissy fit expressed through softare you implicitly trust that gets you. Unencrypted internet transfers have worked and will continue to work for a very long time with very few problems for the vast majority of people. Requiring encryption might be okay, bu…

If you're using GitHub, you've already centralized. git:// support is not being removed from Git or self-hosted repos of any kind.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#109

Post by talideon »

stock_toaster wrote: post #72
OJFord wrote: post #33

Earlier quoted context omitted.

I (submitter) hit this with pre-commit, for whatever reason `pre-commit` hooks all seem to specify `git://` addresses, which had been copy-pasted into our config (some by me). 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 b…

git config --global url."https://".insteadOf git://

I wouldn't be that scattershot, and would instead include "github.com" in the key and value. This is because you may actually want to to SSH clones of non-GH repos, such as if you also deal with Gerrit.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#110

Post by Firehawke »

Xylakant wrote: post #86
Firehawke wrote: post #55

Earlier quoted context omitted.

Yubikey is probably the sanest cross-platform solution. Assuming you're using an updated beyond Microsoft's default version, which you'll need to get from https://github.com/PowerShell/Win32-OpenSSH/releases to have support for USB keys, of course. Hopefully MS will update their included version at some point soon. From there, it's as simple as telling the .ssh/config file to use the key from your Yubikey and you can…

Have you done the setup on windows lately? Because AFAIK, (Fido) yubikey support is still missing. Using either the PKCS#11 support or the gpg applet requires some extra piece of software. Also it required telling git to use that specific ssh version, last time I tried a few month ago, the git installer defaulted to something bundled IIRC. Then, you also want to fiddle with autocrlf and other settings. Git on windows…

Yeah. I'm using it right now. After doing a single-time setup and making sure that I keep a backup of the .gitconfig, etc, I haven't had any problems. I made sure to point Git specifically to the OpenSSH I provided (which I keep in c:\utils\openssh) with the following bit in the .gitconfig file:

[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.

Post reply on HN