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.)
Tell HN: GitHub no longer supporting unauthenticated `git://`
121–130 of 144 posts
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#122Today 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.)
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://`
#123Earlier 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…
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#124Earlier 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…
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://`
#125Earlier 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.
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#126Earlier 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.
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://`
#127Earlier 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.
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#128Earlier 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.
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://`
#129Earlier 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…
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://`
#130Is 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.