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

41–50 of 144 posts

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

#41

Post by [deleted] »

traverseda wrote: post #30
mzs wrote: post #26

Earlier quoted context omitted.

It really wasn't that hard, just created a key pair and added this to my ~/.ssh/config Host github.com Hostname github.com User git IdentitiesOnly yes IdentityFile ~/.ssh/github-id_rsa Lots of other ways to do it as well: https://superuser.com/questions/232373/how-to-tell-git-which...

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…

[deleted]

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

#42

Post by terrorobe »

ihnorton wrote: post #36

This breaks any python package versions that install dependencies via ‘pip install’ from a pinned git+git URL. (For example: google-cloud-cpp 1.23, which was released about a year ago).

Then the brownout had its desired effect.

Using unauthenticated transports for code is borderline malicious.

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

#43

Post by lewiscollard »

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 just thought it might be a helpful PSA for people to keep in mind and maybe remember if something goes wrong

Oh, it was - I'm sure there's a lot of people who are being bitten by this, and nothing I said above should be seen as saying that your post was not useful. :)

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

#44

Post by burnished »

Invictus0 wrote: post #31
stblack wrote: post #29

Earlier quoted context omitted.

Hmmm. Maybe you haven't done that from scratch recently? The deprecation of passwords for tokens is a fairly recent thing. Try it with a fresh laptop: nothing pre-configured. Show someone new how you set up, from scratch. You're gonna be shocked.

I have setup github several times in the last 3 days on fresh Linux installs. It is very easy.

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?

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

#45

Post by alophawen »

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.

This is nonsense. Using git+ssh has been standard for many years now, get on with the time.

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

#46

Post by humanwhosits »

arilotter wrote: post #19
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.)

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…

Brownouts make me lose confidence in the product, simply because it manifests as a failure that needs to be debugged at unknown cost

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

#47

Post by alophawen »

traverseda wrote: post #30
mzs wrote: post #26

Earlier quoted context omitted.

It really wasn't that hard, just created a key pair and added this to my ~/.ssh/config Host github.com Hostname github.com User git IdentitiesOnly yes IdentityFile ~/.ssh/github-id_rsa Lots of other ways to do it as well: https://superuser.com/questions/232373/how-to-tell-git-which...

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…

Nonsense.

You have been able to clone over https since day 1 of Github and still can:

    git clone https://github.com/user/repository

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

#48

Post by alophawen »

stblack wrote: post #28
tialaramex wrote: post #15

Earlier quoted context omitted.

Well, I mean, if you're learning from Rust note that cargo just automatically makes new projects a git repository if that's possible, in the same way it defaults to your new project's code being a trivial implementation of "Hello, world." so that it will build and run before you write any code, and it defaults to providing you a working HTML documentation build and unit test framework. Plus of course it's access to t…

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

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

#49

Post by ghshephard »

arilotter wrote: post #19
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.)

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

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

#50

Post by u801e »

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.

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

But it does require having an account or public key on the server. https does not require having an account, but the http transport protocol is less efficient compared to the native git protocol. If git supported a protocol like gits where it could establish a TLS connection to the server and then use the git protocol for fetch or push, that would be ideal.

Post reply on HN