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

61–70 of 144 posts

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

#61

Post by prepend »

stblack wrote: post #11

Incidentally I'm onboarding someone new to git and Github. I must say, Github is now exceedingly difficult to set up. Vocalizing every step of the process, hopefully not in a hand-wavy way, it strikes me how hard this must be for unguided noobs. 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…

It is hard, but everyone gets through it (or doesn’t). I kind of like it for a filter of whether people can navigate Google/stackoverflow/friends enough to get set up.

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.

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

#62

Post by stnmtn »

alophawen wrote: post #48
stblack wrote: post #28

Earlier quoted context omitted.

Sorry I may have been unclear? 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.

1. go to github and create a new repository ( https://github.com/new ) 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 main

You must understand that the hard part is not this, it's setting up SSH keys and authenticating for someone who

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

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

#63

Post by judge2020 »

prepend wrote: post #60
asveikau wrote: post #37

Earlier quoted context omitted.

I've used git without github quite a bit. I 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.

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://`

#64

Post by rlpb »

traverseda wrote: post #16

It seems like mostly the effects of all these auth changes are twofold * ~~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.

> * ~~Force~~ Encourage people to have github accounts

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.

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

#65

Post by judge2020 »

lewiscollard wrote: post #40
traverseda wrote: post #30

Earlier quoted context omitted.

Of course now every pull is authenticated and they can track exactly what users are pulling from what public repositories. Before it used to be that I only really authenticated when I did a git push. 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 (pre…

> 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. 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 () { mkdi…

GitHub doesn't just need any SSH key, it needs an SSH key attached to an account, probably for abuse/DoS prevention purposes.

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

#66

Post by uranusjr »

OJFord wrote: post #33
lewiscollard wrote: post #21

Earlier quoted context omitted.

> Make using plain git more difficult 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 (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…

I’m curious, where did you get those pre-commit configs from? I’ve seen many projects use pre-commit, and all of them use https. From what I know, pre-commit’s documentation also only provides examples with https repos, not git:, from pretty much Day One. It’s probably a good idea to tell whoever created the config to fix their materials, for more than this particular reason.

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

#67

Post by daenney »

ghshephard wrote: post #49
arilotter wrote: post #19

Earlier quoted context omitted.

Our CI system broke as a result - I really like this "brownout" idea to help us find it before it turns off for good, but a 24-hour period for us to be broken or scramble to fix is kind of a PITA. 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, so that once it happens, we could easily disable the brownout for our repo & schedule working o…

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

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

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

#68

Post by judge2020 »

prepend wrote: post #61
stblack wrote: post #11

Incidentally I'm onboarding someone new to git and Github. I must say, Github is now exceedingly difficult to set up. Vocalizing every step of the process, hopefully not in a hand-wavy way, it strikes me how hard this must be for unguided noobs. 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…

It is hard, but everyone gets through it (or doesn’t). I kind of like it for a filter of whether people can navigate Google/stackoverflow/friends enough to get set up. 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 othe…

To add, the best way to make it not hard for someone is to get them to use https://desktop.github.com, and hopefully they'll eventually expand their curiosity to the cli.

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

#69

Post by OJFord »

uranusjr wrote: post #66
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…

I’m curious, where did you get those pre-commit configs from? I’ve seen many projects use pre-commit, and all of them use https. From what I know, pre-commit’s documentation also only provides examples with https repos, not git:, from pretty much Day One. It’s probably a good idea to tell whoever created the config to fix their materials, for more than this particular reason.

Well I didn't look into it thoroughly, I just wondered how/why we ended up with `git://` (as I say, that's never what I use personally - I knew I wouldn't have written it - but I was to `blame` for some of them) and at least a couple that I checked linked from the list on the pre-commit site to GitHub had a copy-pastable 'add this to your config' with `git://` in the readme.

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

#70

Post by jka »

asveikau wrote: post #37
traverseda wrote: post #16

It seems like mostly the effects of all these auth changes are twofold * ~~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.

I've used git without github quite a bit. I 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.

This seems unlikely, but if you thought that the site that you believe is github.com might be responding to you with tampered data, and you wanted to allow an independent third party to view the bi-directional traffic flowing between you and that entity, then you might want to communicate without encryption.

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

Post reply on HN