Live data from Hacker News

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

news.ycombinator.com

121–130 of 144 posts

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

#122
post #53

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

It seems like the brownout should be publicized on the front page of github.com - or at least githubstatus.com ? (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.)

If there is, it is not at all obvious to me where.

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.

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

#123

Earlier quoted context omitted.

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 pass…

So it’s still as it was when I last set it up: everything is there, but it requires fiddling. I’m using a similar setup right now. One place where Linux has the better experience.

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

#124
post #114

Earlier quoted context omitted.

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…

> Because AFAIK, (Fido) yubikey support is still missing. 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 softwar…

> Correct, hopefully Microsoft will provide an updated SSH client soon. It only requires recompiling OpenSSH with the correct flags.

I checked when Microsoft-owned GitHub announced full Fido support, but I’ve stopped holding my breath.

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

#125
post #60

Earlier quoted context omitted.

It’s great for anonymous clones of public repos where I don’t care about signing in. 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.

I said this in my top comment but https:// also allows unauthenticated access while being encrypted, whereas git:// is unencrypted and can be MITM'd.

I understand the differences. I don’t care about MITM git protocol attacks.

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

#126
post #74
post #60

Earlier quoted context omitted.

It’s great for anonymous clones of public repos where I don’t care about signing in. 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.

Do you like your ISP being able to inject commits into your repo clones? There's nothing wrong with using HTTPS.

I don’t consider that a reasonable risk. And even if it was, then I don’t care for repos I explicitly clone without using encryption.

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.

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

#127
post #67

Earlier quoted context omitted.

> One way to opt out of the brownout would have been to switch to new Auth back in September of last year. Or November of last year after the first brown out. 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.

So why would it be better to learn about those things when the brownout was permanent? Seems like very short-sighted thinking.

I think the idea is that once you know what is going on you can opt out, so that you can put fixing it on your next sprint instead of having to drop everything and fix it right now so you don't lose 24 hours of productivity.

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

#128
post #89

Earlier quoted context omitted.

Hey, I keep bouncing between mac and windows, where/how do you store credentials/tokens? I feel like I've got passwords now that I can't memorize and have to save as text somewhere. I'm putting sensitive stuff in a secrets folder with a corresponding gitignore entry, but I feel like there has got to be some well understood way to handle this?

Credentials/tokens go in environment variables. For development, the convention is to make a `.env` file that's in `.gitignore` and load it into your environment variables. In deployed contexts, you often have a system to do this for you.

What sort of tools read .env files/what do I need to know to comfortably set and read environment variables in PowerShell or Bash? Do you just keep the token there in plain text in the .env file?

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.

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

#129

Earlier quoted context omitted.

I think his point is that SSH keys are the hassle over just entering a password.

This seems wrong. Your public keys are.. public, whereas the password is secret. So you can keep those public keys on a PostIt note, on your home page, a text file pinned to your desktop, send them by email, whatever. 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…

> So you can keep those public keys on a PostIt note, on your home page, a text file pinned to your desktop, send them by email, whatever.

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.

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

#130
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.

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.

Post reply on HN