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
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.
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.
You don't have to force them to log in, replace with https:// and it works anonymously as it did before
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…
> I must say, Github is now exceedingly difficult to set up. My GitHub setup process for myself and new hires hasn't changed in 10 years. I'm a bit flabbergasted at what the difficulty could be. 1. Generate a private/public key pair with openssl 2. Add it to your Github account 3. Done I believe openssl still even comes standard on mac so you don't even need to install anything.
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.
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.)
I'm not impacted, but I wonder if doing a brownout that is ran on odd hours for a week and then a brownout that is ran on even hours for a week would catch more situations and allow people to fix systems without as much fanfare.
You must understand that the hard part is not this, it's setting up SSH keys and authenticating for someone who a) Hasn't set up an SSH key before b) Hasn't used github before It's more of a hassle now than it was 5 years ago
> 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.
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?
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 is a pain, but that’s not GitHub’s fault.
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.
> * ~~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.
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
You could have avoided this failure by upgrading at any point after September 1 when this change was announced.
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?
Credentials/tokens go in environment variables. For development, the convention is to make a `.env` file that's in `.gitignore` and load it into your environment variables. In deployed contexts, you often have a system to do this for you.
> I must say, Github is now exceedingly difficult to set up. My GitHub setup process for myself and new hires hasn't changed in 10 years. I'm a bit flabbergasted at what the difficulty could be. 1. Generate a private/public key pair with openssl 2. Add it to your Github account 3. Done I believe openssl still even comes standard on mac so you don't even need to install anything.
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.