Live data from Hacker News

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

news.ycombinator.com

111–120 of 144 posts

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

#111

Earlier quoted context omitted.

This was not what a lot of people were doing beforehand. We were logging in with our passwords. At least for me when this change was announced, I had no idea what a key pair was as I was always using passwords for everything.

Have you never used ssh? Genuinely curious.

I would bet that a large portion of first time GitHub users have never used ssh, myself included at that time. Anyone teaching themselves to code will find a lot of information right away about git and GitHub, but probably little about ssh until they've gone pretty far past the stage where they create a Hello World script in Python and save it to GitHub.

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

#112
post #64

Earlier quoted context omitted.

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

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

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.

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

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

> What is the difficult part of setting up git?

For an experienced developer, nothing. But for a beginner, two or three of those steps will be very confusing.

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

#114

Earlier quoted context omitted.

Yubikey is probably the sanest cross-platform solution. Assuming you're using an updated beyond Microsoft's default version, which you'll need to get from https://github.com/PowerShell/Win32-OpenSSH/releases to have support for USB keys, of course. Hopefully MS will update their included version at some point soon. From there, it's as simple as telling the .ssh/config file to use the key from your Yubikey and you can…

Have you done the setup on windows lately? Because AFAIK, (Fido) yubikey support is still missing. Using either the PKCS#11 support or the gpg applet requires some extra piece of software. Also it required telling git to use that specific ssh version, last time I tried a few month ago, the git installer defaulted to something bundled IIRC. Then, you also want to fiddle with autocrlf and other settings. Git on windows…

> Because AFAIK, (Fido) yubikey support is still missing.

Correct, hopefully Microsoft will provide an updated SSH client soon. It only requires recompiling OpenSSH with the correct flags.

Alternatively, use these build instruction for openssh with FIDO for windows:

https://gist.github.com/martelletto/6a7cf806c6433ac9ce71d66a...

> Using either the PKCS#11 support or the gpg applet requires some extra piece of software

For those wanting to do that, here are some ways:

Using a premade dll:

https://github-wiki-see.page/m/mooltipass/minible/wiki/Setti...

Or with a middleware:

https://github.com/mgbowen/windows-fido-bridge

Using the Hello API:

https://github.com/tavrez/openssh-sk-winhello

Given how many people came with their own ways, I believe there's enough demand for Microsoft to fix that.

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

#115
post #67

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

[deleted]

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

#116

Earlier quoted context omitted.

So do deprecations.

> So do deprecations. Well, feature removals do. Deprecations are just declaring that a feature should not be used and either will or may be removed in the future, which causes no operational problems (and in fact is done specifically to help avoid the operational problems of feature removals.)

[deleted]

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

#117

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

> Because the next brownout is permanent - and that will be an even bigger PITA.

more like a blackout.

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

#118

git:// is not just unauthenticated, but unencrypted on the wire. They want you to use https:// for unauthenticated clones to at least prevent MITMs.

And in consequence although many people will experience it no longer working, it might still "work" for you (or it might never have "worked") since anybody who is between you and GitHub can decide what happens instead. If you've insisted on building something that insists on using git:// this way, you can proxy it to the safer supported system seamlessly, since you had no way to know before it was correct and you'll…

Git itself has a config flag to tell it to always use https:// instead of git://. It's often been recommended for Windows users of git as sometimes the only way out of some peculiar submodule holes (on a platform where SSH was a second class citizen for many decades).

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

There are versions of that config line more specific to individual hosts if you didn't want to blanked cover every git host, but it's probably a good idea at this point to instead ask those other hosts if they would consider adding https:// support.

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

#119

Earlier quoted context omitted.

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

I think his point is that SSH keys are the hassle over just entering a password.

This seems wrong. Your public keys are.. public, whereas the password is secret. So you can keep those public keys on a PostIt note, on your home page, a text file pinned to your desktop, send them by email, whatever.

Now I understand if your password everywhere is just pass1234 that's easier but, trouble is that means you don't have any actual security. People whose password isn't obvious are clearly better off with keys.

Post reply on HN