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

31–40 of 144 posts

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

#31

Post by Invictus0 »

stblack wrote: post #29
Invictus0 wrote: post #25

Earlier quoted context omitted.

It's really not that hard. Install the GitHub CLI and it gives you a simple setup wizard on first run. The GitHub page for the CLI also has clear and simple instructions on how to install it for any OS.

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.

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

#32

Post by rsync »

tialaramex wrote: post #12
vermilingua wrote: post #3

Earlier quoted context omitted.

Doesn’t git:// transport use SSH? How is SSH possibly unencrypted on the wire?

> How is SSH possibly unencrypted on the wire? Not really a practical answer, as your SSH client doesn't (and shouldn't) offer this, but of course the rest of the SSH protocol just relies on a negotiated arbitrary encryption for moving data between client and server which is transparent to it, you can drop in different algorithms (on most PCs today AES will be the best option because it is hardware accelerated, on ch…

"So, it is technically possible to have a NO-OP encryption layer but just a bad idea."

Not just technically possible - it actually exists. There is a NONE cipher that is part of the HPN-SSH patches, etc.:

https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/

"The NONE cipher switch disables data encryption AFTER you have been authenticated or logged into the remote host. This can significantly reduce the load on the CPUs of both machines and may improve performance even more. Its important to remember that the initial authentication process is still fully encrypted."

If we're sending data over a private point-to-point link we always consider the NONE cipher ... especially if the underlying data was created by borg or restic anyway ...

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

#33

Post by OJFord »

lewiscollard wrote: post #21
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.

> 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 buried in a dependency used in CI, and a python library for running git operations, so you can't even find it by grepping, etc.

So while mine especially wasn't hard to fix, I just thought it might be a helpful PSA for people to keep in mind and maybe remember if something goes wrong.

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

#34

Post by sjcoles »

stblack wrote: post #29
Invictus0 wrote: post #25

Earlier quoted context omitted.

It's really not that hard. Install the GitHub CLI and it gives you a simple setup wizard on first run. The GitHub page for the CLI also has clear and simple instructions on how to install it for any OS.

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.

Create keypair, import public key to GH, set git config values, set git remote, done?

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

#37

Post by asveikau »

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.

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

#38

Post by terrorobe »

traverseda wrote: post #23
outside1234 wrote: post #17

Earlier quoted context omitted.

Or its about preventing MITM attacks, which is a much more likely, much less tin foil explanation.

Taken alone it's pretty reasonable, but it does seem like part of a larger trend. Removing the ability to authenticate with a password using standard git seems to me like a pretty obvious attempt to force people to use the `gh` cli tool.

The main reason to de-emphasize passwords is that they can easily get leaked and can cause long-lasting problems.

Forcing automation to use per-service authentication tokens in the form of distinct SSH keys or access tokens allows you to

* limit the scope of the token when it gets leaked * Using a password gives you full control over a GitHub account, a SSH key or token much less so * verify which credentials are still actively used * deactivate & replace tokens on a more fine-grained level if one should get leaked

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

#39

Post by u801e »

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?

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

#40

Post by lewiscollard »

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…

> 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 () {
    mkdir -p ~/.random-ssh-keys
    KEYNAME=$(openssl rand -hex 12)
    KEYFILE=~/.random-ssh-keys/$KEYNAME
    ssh-keygen -q -C $KEYNAME -N "" -f $KEYFILE
    GIT_SSH_COMMAND="ssh -i $KEYFILE" git "$@"
  }
Problem solved!

...or you could clone over HTTPS instead :)

Post reply on HN