5 ms·

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 diffic

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.

rlpb 5y ago
> * ~~Force~~ Encourage people to have github accounts I switched from git:// to https:// 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.
- gaius_baltar 5y ago
  > 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. Not yet. That's the whole point. It's past the time to move to distributed wikis and issues trackers (perhaps even a Git-based one, like bugs everywhere) so migration will be easier when Microsoft stops baiting and starts switching.
  - KarlKemp 5y ago
    So you’re criticizing them for a sequence of events that exists only in your imagination? And what do you believe needs to happen for MS to switch into “switch” mode? This change isn’t making people more dependent on GH, the number of accounts is probably growing slower than in the past because almost everyone has an account… What’s the piece missing for them to turn to the dark side? I think I’ll wait.
outside1234 5y ago
Or its about preventing MITM attacks, which is a much more likely, much less tin foil explanation.
- traverseda 5y ago
  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.
  - terrorobe 5y ago
    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
lewiscollard 5y ago
> 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.
- OJFord 5y ago
  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:// 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.
  - lewiscollard 5y ago
    > 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. :)
  - uranusjr 5y ago
    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.
    - OJFord 5y ago
      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.
vtbassmatt 5y ago
This change doesn't force you to have a GitHub account. https:// https:// access to public repos doesn't require authentication.
mzs 5y ago
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-private-key-to-use https://superuser.com/questions/232373/how-to-tell-git-which...
- traverseda 5y ago
  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 (presuming you're not behind a university NAT or something), but removing password auth does seem like a pretty clear attempt at gathering more user data.
  - lewiscollard 5y ago
    > 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 :)
    - judge2020 5y ago
      GitHub doesn't just need any SSH key, it needs an SSH key attached to an account, probably for abuse/DoS prevention purposes.
      - 5y ago
gbraad 5y ago
Authentication seems the essential keyword here. Even their npm registry, when configured for a public package, needs an authenticated user before you can pull. This was promised to not be needed over a year ago. We eventually gave up in this as it complicated onboarding new contributors and Ci.
asveikau 5y ago
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.
- u801e 5y ago
  > 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.
  - falcor84 5y ago
    > But it does require having an account or public key on the server. It's a bit of a hassle, but I suppose you could always create a public read-only account with a 'private' ssh key made available in the readme.
- prepend 5y ago
  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.
  - Majestic121 5y ago
    You don't have to force them to log in, replace with https:// https:// and it works anonymously as it did before
  - 5y ago
alophawen 5y ago
This is nonsense. Using git+ssh has been standard for many years now, get on with the time.

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 diffic

rlpb 5y ago

> * ~~Force~~ Encourage people to have github accounts I switched from git:// to https:// 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.

gaius_baltar 5y ago
> 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. Not yet. That's the whole point. It's past the time to move to distributed wikis and issues trackers (perhaps even a Git-based one, like bugs everywhere) so migration will be easier when Microsoft stops baiting and starts switching.
- KarlKemp 5y ago
  So you’re criticizing them for a sequence of events that exists only in your imagination? And what do you believe needs to happen for MS to switch into “switch” mode? This change isn’t making people more dependent on GH, the number of accounts is probably growing slower than in the past because almost everyone has an account… What’s the piece missing for them to turn to the dark side? I think I’ll wait.

outside1234 5y ago

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

traverseda 5y ago
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.
- terrorobe 5y ago
  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

lewiscollard 5y ago

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

OJFord 5y ago
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:// 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.
- lewiscollard 5y ago
  > 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. :)
- uranusjr 5y ago
  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.
  - OJFord 5y ago
    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.

vtbassmatt 5y ago

This change doesn't force you to have a GitHub account. https:// https:// access to public repos doesn't require authentication.

mzs 5y ago

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-private-key-to-use https://superuser.com/questions/232373/how-to-tell-git-which...

traverseda 5y ago
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 (presuming you're not behind a university NAT or something), but removing password auth does seem like a pretty clear attempt at gathering more user data.
- lewiscollard 5y ago
  > 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 :)
  - judge2020 5y ago
    GitHub doesn't just need any SSH key, it needs an SSH key attached to an account, probably for abuse/DoS prevention purposes.
    - 5y ago

gbraad 5y ago

Authentication seems the essential keyword here. Even their npm registry, when configured for a public package, needs an authenticated user before you can pull. This was promised to not be needed over a year ago. We eventually gave up in this as it complicated onboarding new contributors and Ci.

asveikau 5y ago

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.

u801e 5y ago
> 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.
- falcor84 5y ago
  > But it does require having an account or public key on the server. It's a bit of a hassle, but I suppose you could always create a public read-only account with a 'private' ssh key made available in the readme.
prepend 5y ago
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.
- Majestic121 5y ago
  You don't have to force them to log in, replace with https:// https:// and it works anonymously as it did before
- 5y ago

alophawen 5y ago

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