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.
Tell HN: GitHub no longer supporting unauthenticated `git://`
111–120 of 144 posts
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#112Earlier 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.
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://`
#113Incidentally 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..?
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://`
#114Earlier 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…
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://`
#115Earlier 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.
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#116Earlier 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.)
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#117Earlier 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).
more like a blackout.
Re: Tell HN: GitHub no longer supporting unauthenticated `git://`
#118git:// 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 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://`
#119Earlier 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.
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.