Comment by 38 | Hacker News Reader

Comment by 38 | Hacker News Reader

> Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using the same process. The user cannot choose their password, but can get a new randomly generated one in the event of compromise. The password essentially becomes indistinguishable from an API key.

GitHub does this now. you cannot push with your normal password, only a Personal Access Token. I am fine with this, but perhaps the process of setting and getting the token could be streamlined. Currently, you have to:

1. click profile

2. click settings

3. click developer settings (the last item of 24 items)

4. click personal access tokens (again the last item in the list)

5. click tokens classic (again the last item)

6. click generate new token

7. click generate new token (classic)

8. enter password

9. click confirm

10. enter note

11. choose expiration

12. choose scope

13. click generate token

thats just way, way too many steps for the average user.

Personal Access Tokens are intended for fully automated access, such as a deployment pipeline. They are not intended for daily use, and step 4 even explicitly says "Need an API token for scripts or testing?".

For regular pushing you are expected to use a SSH key, and those are far easier to add.

Indeed, but you still need a Personal Access Token to integrate pull requests and issues with your Git client. GitHub doesn't support SSH authentication in those cases.

By git client, do you mean something other than git? Something like a CI system? Even there you can use an SSH key?

I think they mean a desktop GUI application on top of git like GitKraken or SourceTree. These sometimes allow you to perform actions like creating a PR (which is not done via git itself, of course).

  > but you still need a Personal Access Token to integrate pull requests and issues with your Git client

(Nitpick from a former GH employee) PATs really are almost exclusively intended for personal testing with curl and such. The strongly preferred way for apps like you describe to work is a pseudo-OAuth flow (“GitHub Apps”) which yields a token that is not a Personal Access Token. Better in just about every way: more ergonomic, more secure (revocable, shorter duration, predictable fine grain scope with a mechanism for requesting additional permissions as apps change, etc), and requests are attributable to the application which generated them instead of just the user. If you use an app that actually requires generating and pasting a PAT, it’s either extremely old or made by someone who is not prioritizing security and user experience. It even works well in CLI apps, cf. the `gh` command line utility.

I should have clarified; sorry. I was referring to how some editors and IDEs can interact with git repositories. For instance, if I was editing a file that had uncommitted changes, it might display that text in a different colour. Interaction with GitHub might be in the form of browsing pull requests within the IDE.

This is what I do with Emacs using a package called Magit[1]; VS Code comes with something similar.

[1]: https://magit.vc/

GitHub is a development platform, heavily related to tech though. People that are experienced enough to do git push can definitely manage API key-like passwords. This solution is not exactly suitable for any other industry, its literally a call for bankruptcy (unless you are B2B, and even with that, so many tickets, support overload...)

99% of their users, even 99.99% might be programmers, but I was involved with a project where most of the contributors were lawyers. Most of them could only use the GitHub web interface ('edit file', not even the VS Code one) to make changes, so making it easier for them to use git push would be advantageous for everyone involved.

I don’t push with any access token, I push with SSH keys.

An alternative IIRC is to a UI client like GitHub Desktop which lets you login/SSO everything like that, although I’m not sure if that only works because my SSH credentials are configured.

Reply on news.ycombinator.com