[HN Gopher] GitHub: Git password authentication is shutting down
___________________________________________________________________
GitHub: Git password authentication is shutting down
Author : judge2020
Score : 142 points
Date : 2021-08-12 20:12 UTC (2 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| ushakov wrote:
| Embrace. Extend. Extinguish
| jrockway wrote:
| 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.
| HeckFeck wrote:
| Indeed. I wish there was something like a token or key that
| was as ubiquitous as passwords.
|
| Though from a developer POV I can certainly see why passwords
| are so attractive: take a word, hash it, compare hash on
| subsequent logins.
|
| The alternatives are tricky, but not I suspect impossible, to
| do in a decentralised manner. I've often pondered that
| something like PGP servers with revocation certificates, but
| adapted to logins would be near the realm of a solution.
| toiletaccount wrote:
| Do you want to be the one to explain PGP and revcerts to
| somebody who has used the same password for everything
| their whole life?
| HeckFeck wrote:
| That's why I said 'something like'. An extension of the
| idea adapted for wider use.
|
| I'm certain such a person uses TCP/IP every day and
| doesn't need it explained. Yet twenty years ago, some
| knowledge of IP addresses and subnet masks etc was
| necessary to get connected.
| ramesh31 wrote:
| I feel a great disturbance in the force... As if millions of CI
| jobs suddenly cried out in terror, and were suddenly silenced.
| Androider wrote:
| Hopefully they'll enhance the other authentication methods. I was
| quite surprised how complicated yet insecure the GitHub Actions
| and personal access token mechanisms are just last week.
|
| GitHub Actions tokens are scoped to the single repo they operate
| in, so for anything that you need covering any cross-repository
| or org access the official docs immediately tell you to just use
| a PAT instead. But PATs have no repository scoping whatsoever,
| it's all or nothing. So although both PATs and GHA Tokens have
| these complex scope requests, it's completely missing the most
| basic use cases in my opinion, like creating a PR in repo X,
| allow installing a package from GitHub Packages in repo Y, check
| out code from repo Z etc. You either go full mono-repo for
| everything, or you use PATs for everything with no repository
| boundaries at all, yikes.
| Operyl wrote:
| Yeah .. it's not great. Creating a machine user is really the
| only way to do it right now :(.
| Androider wrote:
| And they'll charge you the full seat price for it :/
| foxpurple wrote:
| GitLab now has project access tokens for that.
| kevincox wrote:
| If you have a "project" not a "user". If I'd known this
| in the past I would have just created a "kevincox"
| project and a "kevincox-u" user.
| narraturgy wrote:
| Ok I'll admit it. I'm the dingus who is still using https and
| login/password. It's how I learned to use it years ago and since
| I only ever access GitHub via cli it's all I've ever learned. I
| don't program anything complex and I've never put anything secure
| up on GitHub (it's public, after all, so i had the expectation
| that all info on there is insecure). I don't understand why this
| is being deprecated when it's the default suggestion GitHub
| provides you when you add a new repo to your profile so that you
| can connect your local git repo to it. For hosting my trivial
| personal projects it seems so silly to have to go onto github's
| web interface and click through a bunch of their ui to build a
| personal passkey(which is just a password with a different name
| afaict). I just not the intended audience for the change or am I
| missing something crucial that doesn't make this seem like a
| bunch of extra effort for no meaningful change?
| amiga-workbench wrote:
| Key based auth is much more resistant to phishing. Its just one
| command to have openssh generate a key pair on your computer,
| and you're done. Password auth in general cannot go away fast
| enough.
| Osiris wrote:
| Not in Windows unless you have WOL installed.
| kiwijamo wrote:
| Windows comes with ssh by default these days so you can
| easily ssh-keygen. Doesn't need WOL as I used that without
| WOL.
| the8472 wrote:
| > I don't understand why this is being deprecated when it's the
| default suggestion GitHub provides you when you add a new repo
| to your profile so that you can connect your local git repo to
| it.
|
| It suggests SSH commands by default for me, I assume this
| depends whether you have added an SSH key to your account or
| not.
| runj__ wrote:
| I'm also a dingus and I am sometimes forced to clone private
| repos from new machines which doesn't have my keys. I know that
| ssh-agent is a thing which is sometimes set up but I still
| don't really know how it works, and sometimes it doesn't work
| at all.
|
| I wish there was some way of _manually_ identifying via a
| simple link or QR code or whatever.
| cyral wrote:
| You forgot about the part where you run `git push` later and
| realize it didn't save your passkey, so you have to make
| another one. This time you Google how to save it and copy the
| top answer on StackOverflow, which uses the git credentials
| store to save it in plain text in your ~/.gitconfig file. Now
| is the passkey more secure?
| peterburkimsher wrote:
| Thank you for being humble and describing the ways you use
| GitHub!
|
| I'm the same, and it's reassuring to know that I'm not the only
| one just using it as a free web host for personal projects.
|
| Until starting a new job in January 2021, I "knew git" to the
| extent of git pull, git add, git commit -m, and git push. For
| everything else I just made a copy of the repo. Now I've
| learned a little more about branches and merge requests, but I
| still make a copy of the repo and copy my changes over when
| things go wrong. https://xkcd.com/1597/
|
| Like you, I got some password-related warnings on GitHub, and
| honestly it's scaring me away. I know it'll take an hour or so
| to figure out what went wrong, regenerate a ton of SSH keys for
| every computer I own and link them to my account, disable 2FA
| because my phone number is in another country... I'd rather
| just upload a file, thanks.
|
| The increased overhead means I'd rather just use FTP to upload
| some files to an HTTP server, but I don't think that such free
| FTP web hosts exist any more. At least, not ones with a domain
| that people recognise. That said, peterburk.github.com is no
| longer accessible, only peterburk.github.io, so maybe it is
| time for me to go looking for a free .com subdomain.
|
| I'm grateful for GitHub hosting all the junk I decide to share,
| and I'm obviously not their target market if I'm not paying. I
| just wish there were a place I could drag & drop to upload
| content publicly.
| [deleted]
| [deleted]
| a-dub wrote:
| it seems about the only use case for passwords was cloning a
| private repository in an environment where you don't want keep
| your keys. that said, any environment where you don't want to
| keep your keys isn't necessarily a place you want to be typing in
| your account password anyhow.
|
| human typable one time passwords for this purpose could be cool.
| although it's a pretty rare use case.
| jampekka wrote:
| So now I can't use git client on github repos anymore without
| carrying a device that has some impossible to memorize key or
| token on it?
|
| I hate it. I don't care much for the slight chance that someone
| gets into my github account. I care a lot more that now I have to
| jump hoops to get into my account myself. There's more to things
| than security.
| vtbassmatt wrote:
| Disclosure: I'm the Git Systems PM at GitHub. Opinions are my own
| and I wasn't directly involved with this effort.
|
| GCM Core is a really straightforward way to auth with GitHub and
| several other Git hosts. It comes with Git for Windows by
| default, can be installed with `brew` on macOS, and from a .deb
| on Linux. https://github.com/microsoft/Git-Credential-Manager-
| Core (it started under the Microsoft banner but is maintained by
| GitHub employees now).
| gigel82 wrote:
| GCM still doesn't support multiple users properly, though.
| Https auth is what I was using for a second GitHub account, so
| I'm not thrilled about this change.
|
| I want to have work and personal GitHub accounts on the same
| machine and very explicitly choose which account goes to which
| repo. Too often I have changes going in with the wrong
| user.name / user.email or account to the point where I
| paranoidly reauthenticate every time and manually check each
| clone's .git/config.
| chipotle_coyote wrote:
| Can't you still use https with this? You use the personal
| account token for the specific account to log in as the
| "password". I've been doing this recently with two GitHub
| accounts.
|
| In my ~/.gitconfig file, I've included
| [credential "https://github.com"] useHttpPath =
| true
|
| Which means that the first time -- and _only_ the first time
| -- I try to do something with a GitHub repo that requires
| authentication, I 'll be asked for the username and password
| (token), and I make sure to use the right one. :) At that
| point things stay set.
| lentil wrote:
| While this probably doesn't completely solve your problem,
| have you tried using conditional includes in your .gitconfig?
| I've been using that to ensure that anything under ~/work
| uses my work email for user.email, but anything under
| ~/projects uses my personal email. It's quite handy.
|
| https://git-scm.com/docs/git-config#_conditional_includes
| batuhanicoz wrote:
| I think you can achieve this with an SSH config like
| Host github-personal HostName github.com
| IdentityFile ~/.ssh/id_rsa_personal Host github-
| work HostName github.com IdentityFile
| ~/.ssh/id_rsa_work
|
| Then you can use `github-work` or `github-personal` in the
| remote URL like `git clone git@github-
| work:mywork/somerepo.git`.
|
| edit: I realized after reading the other comments that I got
| the problem wrong! This would push the commits from the
| correct GitHub account but the commits would still have the
| e-mail from git's config and GitHub would link the account in
| the committer e-mail.
| itake wrote:
| Seems odd Github would announce the cutoff time in PST when the
| USA is in PDT.
| spondyl wrote:
| For any Githubbers reading, my coworker was apparently affected
| by a brownout window and changed to using a personal access
| token. He didn't know it at the time but I just mentioned the
| period and it lines up with when had issues with his
| authentication. Seems like a success if you ask me!
| spondyl wrote:
| For any Githubbers reading, my coworker was apparently affected
| by a brownout window and changed to using a personal access
| token. He didn't know it at the time but I just mentioned the
| period and it lines up with when had issues with his
| authentication. Seems like the brownout was a success in our
| case!
| wheybags wrote:
| When will we get repo-specific tokens? That's what I really want.
| As-is, I've just created extra special purpose github accounts,
| but that's a bad solution IMO.
| rmorey wrote:
| I'm guessing that if that's gonna happen (cmon, it's gotta)
| they view this migration is a pre-requisite
| rmorey wrote:
| I'm guessing that if that's gonna happen (cmon, it's gotta)
| they view this migration as a pre-requisite
| orf wrote:
| I wonder how many old, forgotten systems there are out there that
| pull from Github with a password. Brownouts are a smart way to
| try and weed those out, but there are going to be residual
| requests. I wonder how many.
| bastardoperator wrote:
| Looks like they've been doing them for about a year, but
| stragglers are a guarantee!
| polote wrote:
| This is stupid, they only had to request passwords longer than 15
| characters and that would have an even better effect. As web
| access will be also safer.
|
| They do it to prevent password reuse, but still allow passwords
| on the web. I don't get it
| X6S1x6Okd1st wrote:
| You have a much more flexible interface with the user on the
| web than via git push.
| eropple wrote:
| They do it to prevent passwords, which allow access to
| privileged things like account settings, from being stored (and
| thus subject to being accidentally leaked).
|
| It doesn't matter how long your password is if your password is
| in a text file with bad chmod permissions to people who
| shouldn't have it.
|
| An access token, at least, limits the blast radius.
| polote wrote:
| Ah get it. They don't want the password to login on github to
| be the same as the one you store on a text file. Makes sense.
| But it is still Baby-sitting
| eropple wrote:
| What you describe as "baby-sitting", I would call
| "encouraging users to fall into the pit of success."
|
| Many, many GitHub users are not professional software
| developers, and many more than that are not security-minded
| users at all. Small incremental improvements like this are
| a kind of defense in depth, and it is valuable.
| tclancy wrote:
| And we have fifty years of software development history to
| prove we need this kind of babysitting. It's a pain one
| time and then you realize it wasn't hard to do and start
| doing a better practice out of habit.
| kdmccormick wrote:
| Eh, I think everyone stands to benefit when a service
| increases their security standards in a reasonable way.
| Fewer account recovery support requests for them, fewer
| footguns for inexperienced users of theirs.
|
| Do you consider password length requirements baby-sitting?
| nerdponx wrote:
| If this is babysitting, I never want to grow up.
| lanstin wrote:
| I doubt this "saved passwords" is the issue, but people
| choosing guessable passwords. Especially with the bit-coin
| attacks on the Github CI sandboxes, thee attackers don't care
| about the repo that much but they want access to the X% of
| github accounts that use a top 100 or top 1000 password, so
| they can get in and start mining.
| hiimshort wrote:
| 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 terminal commands,
| GitHub, git and its most common commands. It took about 3 hours
| for us to get through just the most basic pieces. Adding on ssh-
| keygen, key management adds even more friction.
|
| It's certainly a difficult problem. How can we offer a more
| gentle learning curve for budding developers while still
| requiring "real" projects to use best practices for security and
| development?
| mynameisvlad wrote:
| Is there a reason one of the many git tutorials online wasn't
| good enough?
|
| https://docs.github.com/en/get-started/quickstart/set-up-git
| https://www.atlassian.com/git/tutorials
|
| This one's always fun: https://learngitbranching.js.org/
| https://www.tutorialspoint.com/git/index.htm
| hiimshort wrote:
| We're taking a 1:1 approach, but most of the time I take
| issue with the language used in many guides. The linked
| guides are good examples, they contain a whole load of terms
| and buzzwords you don't need to know as a beginner.
| AlexandrB wrote:
| Let's look at the tutorial for caching git credentials, which
| is referenced in your first link:
| (https://docs.github.com/en/get-started/getting-started-
| with-...).
|
| It walks you through installing a "cask" using "brew". It
| doesn't mention how to install homebrew but instead directs
| you to the homebrew homepage which shows the output of a curl
| command being fed to `bash -c`. Something that's both bad
| practice and unintelligible unless you're quite familiar with
| Unix shells. _If_ everything works as intended, you 're good
| to go! But if anything goes wrong, or you have to update the
| "cask" in the future you're left with little to no context
| about what you just did.
|
| For someone unfamiliar with Unix shell commands, homebrew,
| curl, etc. this is a quagmire that can take days to unravel
| without someone there to help them.
| geofft wrote:
| Piping the output of curl to bash is not "bad practice" any
| more that downloading an application from your browser and
| clicking on it or downloading a distro CD/USB image and
| booting it up "bad practice."
|
| You have to trust the place where you're downloading it
| from, of course. But there's nothing inherently worse about
| /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.co
| m/Homebrew/install/HEAD/inst...)" than burning
| https://cdimage.debian.org/debian-cd/current/amd64/iso-
| cd/de... and booting it up.
| ysavir wrote:
| Are you teaching a junior at work? What's the context?
| hiimshort wrote:
| In this case it is a younger college student who's interested
| in web development but hasn't done any CS learning and isn't
| generally familiar with tech.
| tcoff91 wrote:
| Does someone who just wants to experiment with a little bit
| of web-dev really need to have version control right away?
| Seems a bit out of scope. That seems like a concept that
| can wait a few months while they actually just explore
| writing some code first.
| mrosett wrote:
| Totally agree on this. So many coding (or even data
| science) courses start with Git which is just not that
| important for a newbie.
| hiimshort wrote:
| > Does someone who just wants to experiment with a little
| bit of web-dev really need to have version control right
| away?
|
| To explain: She wants to eventually work as a developer
| and has a project in mind guiding her. I started her with
| the simplest possible steps and she's been learning html
| & css for a few weeks now with some great progress. She
| got the the point where she was starting to have multiple
| projects she was building for learning. In addition, she
| was starting to feel the pain of "this project is on my
| desktop, but I am going to be away from home for a week
| and will only have my laptop." For those reasons (as well
| as the benefit of introducing GitHub as a place of
| collaboration), we took some a few hours to cover git and
| the terminal.
|
| It didn't seem like we jumped to it too early and after
| those three hours she had the basics which is good enough
| to ensure her projects are safely replicated to GitHub
| and available for her no matter which machine she is on.
| funtime wrote:
| or start with svn or something simpler to get the basics
| of source control.
| WorldMaker wrote:
| SVN was the reason most people when I was in college
| didn't use source control at all. It was painful to
| install on Windows. There weren't good hosts for it. (CSV
| at least had bad old SourceForge.) Once you had it
| installed and had settled on a host computer (and SVN
| needs a host), configuring your repositories in it was a
| whole new mess. SVN is definitely not "simpler".
|
| With git you can install and git init anywhere and go you
| have source control. Moving commits to another machine
| gets us into the complications way above of learning
| GitHub and tools for GitHub, but in terms of 0-60 on
| "start a repository so you can commit changes" it's
| really hard to beat.
| tomrod wrote:
| Github Desktop I've found to be an excellent way to get people
| into git generally. Those with proclivities to GUI get what the
| need, those that like to explore have some initial guardrails.
| brtknr wrote:
| Fifficult indeed
| Animats wrote:
| Setting up this authentication is a huge pain. First, the
| Github site lies to you. It tells me that, having previously
| generated a token, that token has never been used. It's been in
| use for months on one machine. Their web site and their
| repository system are not talking to each other.
|
| Then they want you to generate a new token, in the "new
| format". Then they refuse to generate a token valid for more
| than a year. With a dark pattern where you push the "generate"
| button, but nothing happens.
|
| Then comes dealing with Git itself. If you have a credential
| store file, there's no obvious way to log out of Git so that
| you get prompted for the new "authentication token". So I had
| to find out where it stores that data and delete the file. Then
| I could log back in with the new "authentication token". The
| documentation is written assuming you are using Git for the
| first time, not, as is more likely, updating an existing set of
| repositories.
|
| (Why do I suspect that, at some point in the future, we will
| see "Log in with your Microsoft account?")
| bilalq wrote:
| VSCode has come a long way in making this easier for newcomers.
| The Remote repositories extension basically will open up a link
| in Github to generate the Personal Authentication token to
| associate with your VSCode app and that's it.
|
| https://code.visualstudio.com/blogs/2021/06/10/remote-reposi...
|
| Combined with things like Codespaces, I can see a lot of intro
| classes glossing over some of what's happening under the hood.
|
| That said, I really do think that skills like learning how to
| use a terminal and work through the CLI are necessary for
| developers to grow. It's not so different from how woodworkers
| don't just learn how to use a chisel, but also how to sharpen
| and bevel the tool as well.
| BeefySwain wrote:
| 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 with a detached HEAD, a few commits
| ahead and behind the REMOTE, and halfway through a botched
| merge, you have to figure out how to bail them out of that
| using a GUI you've never actually used. Knowing all this, you
| either teach them git (high short term pain, high chance of
| them just giving up immediately) or you tell them to download
| the first result for "windows foss git gui" and pray that
| history won't repeat itself.
| pjc50 wrote:
| 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".
| omnibrain wrote:
| Relevant xkcd: https://xkcd.com/1597/
| post-it wrote:
| > Think, having your graphics designer able to make commits,
| or having someone who only wants to update docs.
|
| GitHub's web interface is pretty good for this.
| the8472 wrote:
| Until you need them to rewrite history because it consists
| of 20 "fix" and "update" commits.
| WorldMaker wrote:
| Then don't need them to rewrite history? That's kind of
| on you and your own OCD at that point. If you are making
| them use a PR workflow anyway, become friends with git
| options like using --first-parent to shallowly traverse
| the DAG and let git's tools give you a clean view. (Or
| use GitHub's PR Squash options, if you really must
| rewrite history.)
| pbhjpbhj wrote:
| I'm not experienced here, but is using the GitHub website
| perhaps the easiest way to submit a PR, that's how I first
| did it and I think it worked ... I've only really used git
| privately and for pulling code from public projects.
| lsaferite wrote:
| Wouldn't introducing them to Github Desktop be a better first
| start if they are fully unfamiliar with all of the rest of the
| command line stuff?
| outworlder wrote:
| > How can we offer a more gentle learning curve for budding
| developers while still requiring "real" projects to use best
| practices for security and development
|
| Difficult question. In the past, the solution was just not to
| use any of that. A bunch of files inside a random folder in
| your computer that were not version controlled in any way. That
| worked, but that's also the reason I lost most of the source
| code that I've written before/during university.
|
| Version control is not a simple problem. A distributed version
| control system, even less simple. Git has some ergonomics
| issues that may possibly get improved, but the fundamental
| problem is not trivial.
|
| We already have to learn so much to do the simplest of tasks,
| that removing password auth seems to not move the little much,
| if at all.
|
| You can certainly 'postpone' some of this learning, maybe
| that's one route. Back when there were "IDE wars", that would
| be one of the arguments ("we don't have to learn no stinkin'
| CLI"). Some IDEs even had their own, local, "version control".
| At some point you'll have to "pop open the hood" though.
| chrisshroba wrote:
| Just so folks know, you can still use personal access tokens,
| which basically work as per-application passwords. For someone
| just getting started with git, I'd recommend they go to
| https://github.com/settings/tokens, generate a token, and then
| they can just use that as their password when running `git
| clone`.
|
| This will certainly be a little more difficult for newcomers,
| and not very discoverable, but it is there.
| Wowfunhappy wrote:
| Right, but this is also what makes me skeptical of the whole
| thing. I now have a Personal Access Token saved in my
| password manager. When I'm in a disposable VM, and git asks
| for a password (because it's a fresh, disposable VM), I copy
| paste the personal access token out of my password manager
| instead of copying my Github password out of my password
| manager.
|
| Okay, no big deal, I just have to spend an extra second
| searching for the copy password icon since it's not in the
| normal place, but did this really improve my security at all?
| It's just a different password.
| geofft wrote:
| I would guess that " _in my password manager_ " immediately
| puts you into the minority of GitHub users. (Maybe not the
| minority of power users or high-profile software
| maintainers, to be fair, but they care about security for
| the site in general.)
|
| So maybe it didn't improve _your_ security, if you were
| already letting your password manager generate distinct
| passwords, but it almost certainly improves the median user
| 's security, who has come up with a weak password they
| think is strong, and may well use that password on multiple
| websites.
|
| Generating the accout password instead of allowing a user-
| supplied password would also work here (and incentivize the
| use of password managers, if enough websites did it), but I
| would guess getting people onto SSH keys is useful for them
| in general - e.g., it allows them to make 2FA or CAPTCHAs
| mandatory for use of high-abuse-potential features like CI
| or Codespaces.
| RussianCow wrote:
| Presumably, the token is stronger than the passwords most
| people are using.
| foota wrote:
| They can also be revoked more easily.
| xur17 wrote:
| Bingo. Not having to deal with the horrible passwords
| like to use is huge.
| [deleted]
| jareklupinski wrote:
| We just have to normalize it.
|
| Passwords were useful until better alternatives were available,
| and are around now to satisfy authentication based on
| 'something you know'. As long as the necessity is to verify
| something you know or something you have, a private key can be
| more convenient.
|
| People who prefer to enter through doors by entering a PIN
| instead of using a metal key will disagree.
|
| The thing left to do is make maintaining this private key as
| frictionless as adding a metal key to my IRL keychain. The kids
| may have some good ideas :)
| overgard wrote:
| Pins are probably more secure than most metal keys (most
| locks are pickable < a minute)
| young_unixer wrote:
| Teaching git & Github to someone that doesn't know how to use a
| terminal is like teaching calculus to someone that doesn't know
| how to add.
|
| Of course you won't be able to do it in a couple of hours. Most
| people spend years learning the things that are required to
| understand how git works, or at least many months if you want
| to learn in a fast, intensive manner.
| edflsafoiewq wrote:
| Doesn't have anything to do with knowing the terminal or not.
| Before getting up and running with git just involved typing
| git commands. Now one of the least mysterious parts to a newb
| (type in your password!) involves picking an external
| credential store that works on your OS, and figuring out how
| to install it, and setting it up with your PAT, and making
| git talk to it. That's a long way from stuff like "now type
| in git add -A".
| edgyquant wrote:
| Wait what? I just use keys generated by ssh and copied to
| GitHub it was way more straight forward than the git
| commands themselves to work on a given repo.
| edgyquant wrote:
| Yeah. I start using git for personal projects in 2015 and
| didn't even know about git diff until last year. All I knew
| was how to git add, git commit, pull and push. If anything
| tricky happened I just copied my changes, deleted the repo
| and recloned. I don't think you need to teach git beyond
| those few commands to people but even then I've been using
| bash since I was a kid playing with openSuse so I'd imagine
| there's a lot of bash experience that made it easier for me
| to pick up. I can't imagine someone who's never typed ls will
| have an easy time picking it up.
| bsder wrote:
| And yet I can teach TortoiseHg to CEOs and secretaries in
| less than an hour.
|
| But, hey, git is sooooo superior. </s>
|
| GitHub has done almost as much damage to version control as
| PowerPoint has done damage to presentations.
| infogulch wrote:
| I don't know how disruptive this will be, but there are many much
| better options to authenticate against github besides a password.
| alpb wrote:
| tldr Git SSH protocol will still support authentication via
| username:password but in this case, the "password" can no longer
| be your Github Account password, but it can be a Personal Access
| Token.
|
| So no need to panic if you've been using a build system or other
| tool that authenticates with username:token instead of a SSH key.
| justinator wrote:
| TLDR? The article was three sentences!
| geerlingguy wrote:
| Well, the comment was two :D
| nemetroid wrote:
| This change affects HTTPS access, not SSH.
| striking wrote:
| https://github.blog/2020-12-15-token-authentication-
| requirem...
|
| Workflows affected:
|
| * Command line Git access
|
| * Desktop applications using Git (GitHub Desktop is
| unaffected)
|
| * Any apps/services that access Git repositories on
| GitHub.com directly using your password
| nemetroid wrote:
| Which one of those is non-HTTPS?
| verdverm wrote:
| git@github.com:org/repo where you've set it up to use
| username:password
|
| People who've put this information in a netrc file may
| see downstream issues in several applications which auth
| with info found therein
| daxuak wrote:
| I have a noob question: what's the right way to use these tokens
| without password managers? I believe Github recommended assigning
| it as an environment variable in docs related to this
| deprecation, but isn't a (managed) server free to log the output
| of `echo $token`?
| bastardoperator wrote:
| Use SSH and GPG to authenticate and sign commits, it's easier
| and quicker. If you're doing something that needs a token use a
| GitHub App Token:
|
| https://docs.github.com/en/developers/apps/getting-started-w...
| geofft wrote:
| If there's a managed server you don't trust, it's unsafe to put
| _anything_ that authenticates you to GitHub there, because it
| can (e.g.) modify the git command to push malicious code.
|
| For a semi-trusted machine (e.g., you want to "git push" to
| work-related OSS from your work desktop, but you don't want
| your work HR/IT departments to have full access to your GitHub
| account if they decide they want it), make a new SSH key and
| configure it as a read/write deploy key for that one repo. This
| workflow is primarily intended for automation, but it's
| reasonable for this sort of interactive use as well.
|
| https://docs.github.com/en/developers/overview/managing-depl...
| eropple wrote:
| One probably has to assume at least some level of control of
| any system where there's access to secrets where they're
| necessary for production processes.
|
| But if you _aren 't_ confident of it, then at least that token
| only has access to a repository, and can't be exfiltrated to
| let somebody log in and really mess with your user account or
| your organization.
|
| (All that said: I'd recommend a single-use, minimally
| privileged SSH key over an access token, just because that
| workflow's what you should be using on a desktop too.)
___________________________________________________________________
(page generated 2021-08-12 23:00 UTC)