Live data from Hacker News

Git password authentication is shutting down

github.blog

321–330 of 353 posts

Re: Git password authentication is shutting down

#321

I'm fine with this change for my usage, I don't think I've used password auth for myself or any automated service I've setup for years now. However, this will introduce more confusion for newcomers who already have to figure out what Git, GitHub, etc are. I just spent some time last weeekend teaching someone the basics of how to create a new project. Such a simple idea required introducing the terminal, basic termina…

I also have found teaching someone how to be even marginally capable of contributing to a Github project from scratch to be a very time consuming and frustrating thing. Think, having your graphics designer able to make commits, or having someone who only wants to update docs. The worst part is the "easier" solutions are actually just footguns in disguise, as soon as they accidentally click the wrong thing and end up…

Yup, most git UIs or wrappers help someone do the most basic operations without learning any git.

The problem is, as soon as someone needs any of the non-basic operations, they're completely stuck, and have to start out by learning the basics (which they've managed manged to avoid so far).

Plus, each implementation makes up its new terms and abstractions.

Re: Git password authentication is shutting down

#322
post #100
post #48

Earlier quoted context omitted.

The solution that everyone actually uses until they learn the unnecessary details is "take a backup of relevant files and blow away & redownload the repo".

wait there is another way?

Invest in (or build?) an enterprise content management system for people that don't, for whatever reason, think of SCM in terms of commits, branches, and graphs.

If you can make one that thinks in terms of git on the backend, great.

If you want to go a bit further, you could expose the underlying operations to the user. You will need to get them to reason around and interact with the minimal requirements inherent to a versioning system, namely explicit versioning and an explicit commit process, along with explicit merging and conflict resolution.

There are GUI clients that help with some of this, but you're not going to get away from some concept of dealing with branches and merges in any SCM. You hear about it less often, but you'd have the same troubles dealing with a chewed up repository in Perforce, ClearCase, or the like.

(edit: even Subversion!)

Re: Git password authentication is shutting down

#324
post #266

Earlier quoted context omitted.

Passwords are probably one of the worst things to happen to our field as a whole (phishing, password managers, etc. are the results of their ubiquity), so efforts to remove them are probably not part of some Microsoft plan to kill open source. This change is a good thing.

Not everything needs perfect OpSec. sometimes convenience is more important. I don't care if my HN account gets hacked and if I was forced to use 2FA I would just stop using it. Passwords have security vulnerabilities, sure. But they're intuitive and usable. When you start trying to come up with alternatives there become dozens of edge-cases in which your system fails.

Passwords are exceedingly inconvenient, and getting rid of them doesn't require adding a second factor. To use passwords, you have to constantly monitor the Internet to see if it's been leaked (in the case where you use a password and memorize it), or you have to subscribe to a third-party service to manage your passwords. To use WebAuthn, you just need the functionality built into your OS. Physical custody of your computer and the screen lock then protect your online accounts.

Or in the case of Github, you generate an SSH key and put the public key in Github and keep the private key around.

Both are much more convenient than passwords, but also more secure. It's a win/win.

Re: Git password authentication is shutting down

#325

Earlier quoted context omitted.

If "git pull --rebase" succeeds without reporting a merge conflict, then it's tantamount to having executed the command with "--ff-only". I believe you are incorrect however. "git pulll --rebase" will not ever rewrite history from the origin repository. It will only ever modify your local unpublished commits to account for new commits from the origin branch. If your change and the new commits from origin aren't touch…

> I was in the habit of committing and pushing to the private repo about once every 30m-1h (to eliminate the chance of major work loss due to hardware failure). I get pushing every day, but how unreliable does your PC have to be if you feel you need to push every hour??? > (And even that operation would show up in the system's logs, so in the case of something like credentials you'd additionally contact the security…

> how unreliable does your PC have to be if you feel you need to push every hour???

Hey, I commit and push on a branch on my fork of the repo every time my unit tests work and sometimes if they don't.

It's a single command, `gi`. My joke is "commit/push is the new save" though I'm not that bad...

No one but me has to see that branch. I rely on my rebasing skills and a library of git tools to produce a small number manicured commits out of it with no work.

It works so well. For one, if I am going from one machine to another, I can literally work and then step off my machine and continue on the other with a pull but no interruption.

At any time, I can just send someone a question with a permalink to the code as it was at that moment, and keep working while waiting for the answer.

I never have much uncommitted work in the current branch, so I can almost immediately start a new bugfix in an emergency.

> The only valid action for leaked credentials is to invalidate them,

Quoted for truth.

Re: Git password authentication is shutting down

#326
post #209

Earlier quoted context omitted.

I also have found teaching someone how to be even marginally capable of contributing to a Github project from scratch to be a very time consuming and frustrating thing. Think, having your graphics designer able to make commits, or having someone who only wants to update docs. The worst part is the "easier" solutions are actually just footguns in disguise, as soon as they accidentally click the wrong thing and end up…

> I also have found teaching someone how to be even marginally capable of contributing to a Github project from scratch to be a very time consuming and frustrating thing. Think, having your graphics designer able to make commits, or having someone who only wants to update docs. The question really should be why do we want to use git for version control when people really want an backup system where they can essential…

Frontend developers really like their designers to have versions, because it handles the eternal:

Designer: Hey, I filed a bug for this, it doesn't look like the design.

Developer: Um, we released that like two weeks ago; it's correct according to the design I had at the time.

Designer: Yeah, but this is the design Maybe you can just fix it really quick today?

Doesn't have to be git, but some way to match up releases to the design document that was current at that time is quite useful.

Re: Git password authentication is shutting down

#327

Earlier quoted context omitted.

You can use Access Tokens which are "application specific" passwords instead of SSH keys. You can use a git credential manager such as GCM Core ( https://github.com/microsoft/Git-Credential-Manager-Core ) to automate the flow from username/password to access token. (It pops up a browser window where you login, retrieves and access token for you.)

Sounds a lot like a hoop. With password I can use any device with git installed to pull and push from/to github repos. Now I'd need a hack like this on top. I prefer less tools to more tools. Probably a losing battle given how the field is developing.

GCM Core is installed out of the box with official git installer on Windows. Several Linux distributions at this point include it as well. On macOS it is a simple brew install away.

git itself was built as an agglomeration of multiple tools bundled together and GCM Core is right on the borderline of a tool always included in the git distribution anyway on some platforms and needs to be installed on others. It's likely to always be in that "weird border space" because it requires a web browser and there isn't a pure command line equivalent.

Re: Git password authentication is shutting down

#328

Earlier quoted context omitted.

You can use a supporting Git Credential Manager (such as GCM Core: https://github.com/microsoft/Git-Credential-Manager-Core ) to keep using HTTPS and login/password. Instead of typing in your username/password directly in the CLI, it pops up GitHub's login page where you input login/password and then does the dance for you to get an access token from that. (Git for Windows default installs GCM Core. Some Linux distro…

Wait til you work in a corporate environment where core doesn't work but the original GCM does. They bungled that transition.

That sounds painful, and in having my own share of dumb corporate papercuts in my environment I sympathize. I'd also point out and echo the sibling comment that the few times I've had GCM problems, the GitHub Issues have helped me debug and fix it (either having an existing Issue with enough details to correct it myself or responding quickly when I've needed to post something).

Re: Git password authentication is shutting down

#329

Oh great. More security theater. This should be a per repository setting. Not system wide! If someone has a "threat model" where "passwords are bad" then fine. Force users interacting with that particular repository to deal with this security theater of making tokens which have the same power as the account that authorized them. I guess they have better granularity, but in practice anything more complicated that Unix…

they just don't want to maintain that code path anymore for whatever reason. its their product, their choice. you're just along for the ride.

Re: Git password authentication is shutting down

#330
post #119

Earlier quoted context omitted.

Not really. People say stuff like this, but what they're really talking about is their own familiarity with GitHub (in the vein of http://lighttable.com/2014/05/16/pain-we-forgot/ >). What GitHub has going for it is that it is familiar to ("a majority of"?) working developers, and that it's better than both the competition and the Git CLI itself, but from a reality-adjusted perspective, GitHub is pretty bad, too. (Th…

I mean you could have stuff that requires prs, but you could just use the ui pretty much like a wiki. 1. Go to dev branch 2. Find file and edit it 3. Commit change

That's not "pretty much like a wiki". That's the antithesis of a wiki. You've just described what the wiki was created to replace.
Post reply on HN