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

71–80 of 144 posts

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

#71

Post by lewiscollard »

judge2020 wrote: post #65
lewiscollard wrote: post #40

Earlier quoted context omitted.

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

Shit, you're probably right. It only worked because I didn't tell SSH to only use the specified identity files (I threw it together in five minutes without really testing it, you can forgive me). Changing one of the lines to this (which it should have been all along):

    GIT_SSH_COMMAND="ssh -i $KEYFILE -o IdentitiesOnly=yes" git "$@"
...comes up with "Permission denied (publickey)". So, yep, you're 100% right.

Oh well. There's still HTTPS!

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

#72

Post by stock_toaster »

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…

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

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

#73

Post by StrangeWill »

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…

We've been using SSH keys by default for all of our new users for years, removes a ton of confusion and starts them with one of the better authentication methods out of the gate.

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

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

#74

Post by eptcyka »

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.

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

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

#75

Post by nemothekid »

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…

>I must say, Github is now exceedingly difficult to set up.

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.

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

#76

Post by zozbot234 »

u801e wrote: post #39
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.

I've read that for fetching and pushing, the http protocol is less efficient compared to the git protocol. Could a remote helper be used to establish a TLS connection to the server and use the git protocol over that connection?

> I've read that for fetching and pushing, the http protocol is less efficient compared to the git protocol.

This was true in the past, but the newer "smart" http protocol has content negotiation similar to the git and ssh protocols.

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

#77

Post by nemothekid »

stnmtn wrote: post #62
alophawen wrote: post #48

Earlier quoted context omitted.

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

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

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

#79

Post by BossingAround »

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…

What is the difficult part of setting up git?

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

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

#80

Post by whimsicalism »

daenney wrote: post #67
ghshephard wrote: post #49

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

So why would it be better to learn about those things when the brownout was permanent?

Seems like very short-sighted thinking.

Post reply on HN