[OT] github access for developers

[duncan]

The short question:

How do you now access your fltk forks at https://github.com/username/fltk ?

Specifically, what is your preferred method of two factor authentification, etc ?

[TL;DR]

Albrecht just accepted a pending pull request of mine relating to documentation

so I thought I would tidy up my local git repository and my fork on github to remove

the obsolete branch. I originally set up github access via https but now I get:

$ git remote -v

origin  https://github.com/username/fltk.git (fetch/push)

upstream  https://github.com/fltk/fltk.git (fetch/push)

$ git pull upstream master

...

$ git push origin master

...

remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead

remote: Please see https://github/blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more info

fatal: Authentication failed ...

So my question, which method do you use, and which authentication tools/apps, if any?

I've been through the link several times but can't work out which is the best way to go

especially as I've seen elsewhere that the recovery codes can be superseded in some

cases which means you can be locked out.

Cheers

D.

P.S. Does this also need to be updated in the GIT for FLTK developers article?

[Albrecht Schlosser]

On 11/17/21 1:11 PM duncan wrote:

The short question:

How do you now access your fltk forks at https://github.com/username/fltk ?

Specifically, what is your preferred method of two factor authentification, etc ?

The short answer: I'm using 2FA with FreeOTP (Android app) for login to GitHub and ssh access for `git push`.

[TL;DR]

Albrecht just accepted a pending pull request of mine relating to documentation

so I thought I would tidy up my local git repository and my fork on github to remove

the obsolete branch. I originally set up github access via https but now I get:

$ git remote -v

origin  https://github.com/username/fltk.git (fetch/push)

upstream  https://github.com/fltk/fltk.git (fetch/push)

$ git pull upstream master

...

$ git push origin master

...

remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead

remote: Please see https://github/blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more info

fatal: Authentication failed ...

If they still tell you to use a personal access token then you can go to your account setup and create such a personal access token. This is IMHO nothing but a long password and you should be able to use it instead of a password with https:... But I'm not using this anymore because I'm using ssh with public/private key authentication.

So my question, which method do you use, and which authentication tools/apps, if any?

As said above, I'm using FreeOTP for the second factor, but there are lots of tools that let you generate a time based (6 figure) access token. Google authenticator is (IIRC) one of them.

I've been through the link several times but can't work out which is the best way to go

especially as I've seen elsewhere that the recovery codes can be superseded in some

cases which means you can be locked out.

Hmm, I'm not aware of cases when the recovery codes can be superseded by any means other than using them or creating new ones. I saved mine and hope this doesn't happen. I believe (but I'm not sure) that you can also leave your phone number for a callback or SMS code or some such.

My experience with GitHub docs is that you turn in circles if you want to read the "whole" docs about a topic. Unfortunately.

If you ever set up ssh access with a public/private key the ssh setup docs are more or less straight-forward, particularly if you're doing this on a Linux system like me. If you have only Windows and never did it yourself before this might be a little harder.

Anyway, my recommendation is ssh with public/private key for `git push` and 2FA with OTP (FreeOTP) for one time tokens (which is different from that "personal access token" you can use for https access).

HTH

Cheers

D.

P.S. Does this also need to be updated in the GIT for FLTK developers article?

I wrote "GitHub has lots of information (help pages) regarding this and I don't want to duplicate this information. Please follow the links below..."

It's not my lazyness but I believe that nobody can describe this better than the GitHub folks themselves.

[imacarthur]

On Wednesday, 17 November 2021 at 12:11:37 UTC duncan wrote:

The short question:

How do you now access your fltk forks at https://github.com/username/fltk ?

Specifically, what is your preferred method of two factor authentification, etc ?

OK, so... what I did was set up 2FA by SMS, but I'm not sure I'd describe that as my "preferred" method, it was more an "Oh, I don't have a TOTP app on my phone... I'll just use SMS, that'll do for now."

And I kinda meant to change that at some point... but then I never quite did.

(Also, I have the GH desktop UI thing on one of my laptops, and it must be using some form of "internal" token anyway, since it seemed to just go on working...)

I feel like I ought to be using a TOTP app to access GH (and "things" more generally, I suppose) but never quite got around to it.

Um... so... does anyone have any recommendations for a TOTP app that I can have on my phone, say, and that they think works well?

At work we have physical RSA dongles, and they seem to work well enough, but I can't use that for "personal" stuff of course, and a phone app might be more "convenient" than a separate physical device anyway.

Suggestions?

[Albrecht Schlosser]

On 11/17/21 4:01 PM imacarthur wrote:

I feel like I ought to be using a TOTP app to access GH (and "things" more generally, I suppose) but never quite got around to it.

Um... so... does anyone have any recommendations for a TOTP app that I can have on my phone, say, and that they think works well?

I'm using FreeOTP (https://freeotp.github.io/) as I wrote before. It's open source on GitHub.

Rumors say that you can read out the "secret" from the phone though. This may be a security issue (don't lose your phone).


Some password safe apps may also be able to generate the tokens once you set them up with the necessary definitions. I know that KeePassXC can do this.

There are also some Linux programs that can generate the tokens. I experimented a little with one of them (don't remember which one) and for me the problem was that I needed to enter the secret on the commandline. However, there are also open source libraries  so you can write your own TOTP generation programs pretty easily (never did that though). The standard is not too complicated to do it even from scratch if you like. ;-)

[imacarthur]

On Wednesday, 17 November 2021 at 12:11:37 UTC duncan wrote:

...

remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead

remote: Please see https://github/blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more info

fatal: Authentication failed ...

Apropos of nothing much, I just tried to click that link and it failed...

It *looks* to me like the correct URL is:  https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/

instead. (That is, "github.blog" rather than "github/blog" here...)

Weird one.

 

[imacarthur]

And that's double-plus-annoying because it seems to have embedded the incorrect URL in my attempted correction, too!

Try again:  https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/

See if that's any better!

[duncan]

My experience with GitHub docs is that you turn in circles if you want to read the "whole" docs about a topic. Unfortunately.

[ . . .]

 

There's too much online documentation where You are in a maze of twisty passages, all different :-)

P.S. Does this also need to be updated in the GIT for FLTK developers article?

I wrote "GitHub has lots of information (help pages) regarding this and I don't want to duplicate this information. Please follow the links below..."

I understand where you're coming from, but a one-line comment about needing to set up 2FA etc might be enough of a hint.

It's not my lazyness but I believe that nobody can describe this better than the GitHub folks themselves.

 See your previous comment :-)

D.

[duncan]

Apropos of nothing much, I just tried to click that link and it failed...

Sorry, my bad. I didn't cut and paste. I was looking at one screen and typing on another :-(

[Albrecht Schlosser]

On 11/17/21 5:58 PM duncan wrote:

P.S. Does this also need to be updated in the GIT for FLTK developers article?

I wrote "GitHub has lots of information (help pages) regarding this and I don't want to duplicate this information. Please follow the links below..."

I understand where you're coming from, but a one-line comment about needing to set up 2FA etc might be enough of a hint.

OK, yes, you're right, thanks for the heads-up. I wrote this article way before 2FA became a requirement and I intended to add more info anyway. Time went by and I've been busy with other stuff.

I should really add a note about 2FA, but please don't hold your breath...

It's not my lazyness but I believe that nobody can describe this better than the GitHub folks themselves.

 See your previous comment :-)

;-)

Well, they really *can* describe it better than I could with all the different options. The question is how they do it and how easy it is to find the appropriate information if you need it. :-(

[duncan]

I wrote:

How do you now access your fltk forks at https://github.com/username/fltk ?

Specifically, what is your preferred method of two factor authentification, etc ?

Ian wrote:

OK, so... what I did was set up 2FA by SMS, but I'm not sure I'd describe that as my "preferred" method, it was more an "Oh, I don't have a TOTP app on my phone... I'll just use SMS, that'll do for now." And I kinda meant to change that at some point... but then I never quite did.

Albrecht wrote:

> I'm using FreeOTP (https://freeotp.github.io/) as I wrote before. It's open source on GitHub.
> Rumors say that you can read out the "secret" from the phone though. This may be a security issue (don't lose your phone).

I've been round and round the houses trying to decide how to proceed because

as I said, people have reported  being locked out after overwriting recovery codes:

e.g. https://www.youtube.com/watch?v=LKGhViHLsbU

and there's also the hassle if you change/lose your phone.

As far as I can see, the commercial one-time-password tools/apps such as

Authy, 1Passwd, etc lock you into their own encrypted vault system stored on

their central servers and you have to start from scratch, with recovery codes,

then disable and re-enable 2FA on each account if you ever want to change tools.

The one I have found that seems more flexible, but I could be wrong, is

Aegis Authenticator ( https://getaegis.app/ ) another open-source tool.

Like FreeOTP it stores the vault locally on your phone, but Aegis also lets

you password-protect the vault, and export it elsewhere for safety.

I'm still hesitant about taking the plunge because the weakest part of the

system is keeping the recovery codes safe.

I'm wondering whether it will be enough to save copies of them in encrypted

folders backed up and in sync across several computers, hope that nobody

steals both phone and computer at the same time, and then use a password

that is "twinned with"  the Aegis vault one on the phone so I won't forget it in

two year's time when I might actually need it, e.g. Laurel & Hardy :-)

Does anyone have a better suggestion? Or are you all using cloud-based

encrypted password manager systems anyway rather than relying on the

local system/browser to remember passwords for you?

D.

[imm]

On Sat, 20 Nov 2021, 15:24 duncan wrote:

Does anyone have a better suggestion? Or are you all using cloud-based

encrypted password manager systems anyway rather than relying on the

local system/browser to remember passwords for you?

So... Motivated by this discussion, I did go looking for a TOTP app. 

Initially I went for FreeOTP as Albrecht suggested, but then, reading various posts I found some folks grumbling about how hard it all was to transition to a new phone... And *this* phone is getting older...

So, after yet more reading, I actually switched to Aegis Authenticator, which I note you also considered. My reasoning was basically that you are able to export the key database and import it on a new phone...

I looked at their design description and it's pretty convincing though the key length that secures the database could be longer... 

As to storing passwords and recovery keys, I'm using f-secure key, FWIW, and that's been OK so far!

--

Ian
From my Fairphone FP3
 

[Albrecht Schlosser]

On 11/20/21 4:24 PM duncan wrote:

I wrote:

How do you now access your fltk forks at https://github.com/username/fltk ?

Specifically, what is your preferred method of two factor authentification, etc ?

Ian wrote:

OK, so... what I did was set up 2FA by SMS, but I'm not sure I'd describe that as my "preferred" method, it was more an "Oh, I don't have a TOTP app on my phone... I'll just use SMS, that'll do for now." And I kinda meant to change that at some point... but then I never quite did.

Albrecht wrote:

> I'm using FreeOTP (https://freeotp.github.io/) as I wrote before. It's open source on GitHub.
> Rumors say that you can read out the "secret" from the phone though. This may be a security issue (don't lose your phone).

I've been round and round the houses trying to decide how to proceed because

as I said, people have reported  being locked out after overwriting recovery codes:

e.g. https://www.youtube.com/watch?v=LKGhViHLsbU

and there's also the hassle if you change/lose your phone.

I watched the video. I agree that it's somewhat confusing if you create new recovery codes but don't complete the setup and these recovery codes are not valid (the old ones are still valid). OK, that's a warning. A good warning. But once you know that you should be able to do the right thing.

As far as I can see, the commercial one-time-password tools/apps such as

Authy, 1Passwd, etc lock you into their own encrypted vault system stored on

their central servers and you have to start from scratch, with recovery codes,

then disable and re-enable 2FA on each account if you ever want to change tools.

Whenever I set up 2FA I'm trying to get the original values (secret, timers, etc.) from the output. GitHub, for instance, lets you continue w/o using the barcode in a "text mode" where you can see all setup parameters. You can also scan the barcode (of GitHub or any other system) with a standard QR code reading app and view the text which contains the setup. One way or the other, I store the parameters for myself in a safe place.

If it happens that you want to change your password / 2FA storage app you can access the original parameters and enter them into the new system. You don't need to setup 2FA on any system again to get *new* parameters and store those. Unless you don't trust your previous cloud provider and *want* to set up new 2FA parameters which is a good choice anyway.

The one I have found that seems more flexible, but I could be wrong, is

Aegis Authenticator ( https://getaegis.app/ ) another open-source tool.

Like FreeOTP it stores the vault locally on your phone, but Aegis also lets

you password-protect the vault, and export it elsewhere for safety.

I'm still hesitant about taking the plunge because the weakest part of the

system is keeping the recovery codes safe.

Yor can always print them on paper and store this in a safe outside your home for additional safety.

I'm wondering whether it will be enough to save copies of them in encrypted

folders backed up and in sync across several computers, hope that nobody

steals both phone and computer at the same time, and then use a password

that is "twinned with"  the Aegis vault one on the phone so I won't forget it in

two year's time when I might actually need it, e.g. Laurel & Hardy :-)

A piece of paper in a safe place ... (?)

Does anyone have a better suggestion? Or are you all using cloud-based

encrypted password manager systems anyway rather than relying on the

local system/browser to remember passwords for you?

I don't trust clouds. I'm storing my passwords in a local password manager (KeePassXC) in an encrypted password database. I'm maintaining the database mostly on one system and copying it to other systems when I think I need it (new or changed passwords). This maintenance burden is the price I'm paying deliberately for not storing my passwords "in the cloud".

KeePassXC can also export all data to either csv or html. I'm doing this as well from time to time fo be able to view everything. KeePassXC warns and asks for confirmation to store the data unencrypted. This is not an issue for me because I store it on an encrypted volume. I store backups of my encrypted files on several external disks (of course, encrypted as well).

Does this qualify as a "better suggestion"?

BTW: since KeePassXC can also store your TOTP (2FA) parameters and generate the tokens this can also be used to store the TOTP parameters in an encrypted database. But, of course, take care to not store both factors (password and 2FA parameters) in the same database that's unlocked with one password. Paranoia is greeting ;-)

PS: since you (Duncan) and Ian mentioned Aegis Authenticator I'll take a look at this too, thanks for the hint.

[duncan]

BTW: since KeePassXC can also store your TOTP (2FA) parameters and generate the tokens this can also be used to store the TOTP parameters in an encrypted database. But, of course, take care to not store both factors (password and 2FA parameters) in the same database that's unlocked with one password. Paranoia is greeting ;-)

OK, I'm almost there. The thing is that the GitHub docs are not very clear on the consequences of 2FA

in terms of how everything fits together. If I understand correctly, GitHub want to secure accounts by

enforcing 2FA. This creates a personal access token (PAT) which is basically "the secret" which is used

to configure whichever authenticator app, and to generate recovery codes. You need to store the PAT

and recovery codes securely. Authy, 1Password, etc. store this info in a proprietary format in the cloud,

i.e. on their servers, so you are locked in to them, and can't work off-line (and you might have to pay).

Other apps, such as Aegis Authenticator, are open source and flexible, but you have to store securely.

KeePassXC allows you to store your username/password pairs for each site, plus data such as the PAT,

and also stores attachments, such as your recovery codes. You have to store the database securely.

If you want to push to GitHub using HTTPS you have to enable 2FA (which means login via token)

and pushing using the PAT instead of your password.

If you want to push to GitHub using SSH you don't have to enable 2FA to login to the site, so you

don't need the PAT, but you do need to generate and save SSH keys.

My big fear is that I screw up the configuration of one or more of these parts somewhere along the way

and I get locked out, but I'm leaning towards setting everything up this weekend to use 2FA on GitHub,

but leaving my mobile phone as the fallback authentication number if all else fails. I shall store the PAT

as a Note to the entry in KeePassXC, the recovery codes as an attachment, and shall store the database

file elsewhere too.

I shall then use the PAT as the secret for Aegis Authenticator on my Android Phone as a backup system

because I think I shall be forced to use a PAT with HTTPS access to the enterprise GitLab at work and I

have less flexibility about what I can install on the corporate machine :-(

The one thing that isn't clear to me is, if I enable the KeePassXC browser extension, does it wipe, or

block access to other username/passwords that I might have already saved in the browser?

Do I have to open the preferences, or Mac keychain, and copy then out manually just to be safe?

Basically, I don't think I'll use the browser-plugin because nobody talks about this!

Why is it so complicated? Or is it that I'm just a 60-year-old bear with little brain who is over-thinking it ? :-)

D.

[duncan]

@Albrecht:

Finally, I've put together the basis of a "Git for FLTK Contributors" article based on the above.

However, I didn't know that you can "Fetch upstream" in GitHub, hence the 3-repo system.

I used your git format-patch text, so you can use, cannibalize, delete the rest as you see fit,

especially as I'm not sure that I've got everything 100% correct until I try to set it up :-(

D.

Git for FLTK Contributors

There are basically three levels at which you can contribute to FLTK bug fixes and new features.
Each workflow has its own pros and cons and likelihood of success.


1. Ad hoc comments and code snippets on the FLTK mailing lists or via GitHub issues.

    Code submissions are always welcome, but the unstructured nature of the mailing lists
    may mean that useful contributions may be overlooked or lost in the general traffic or
    are hard to find when a developer has the time to investigate.

    The advantage of submitting a GitHub issue is that there’s a common space where
    the contributors and the developers can discuss the pros and cons of the suggestion.

    However, the FLTK code base is constantly evolving, in some areas more than others,
    and so there may only be a small window of opportunity to apply those changes.

    The other drawback is that the contributor’s name may not be obvious in the git logs.


2. Submitting patches based on an up-to-date local clone of the FLTK repository.

    Git provides a structured way of generating patch files relating to a known state or
    “commit” in the master branch of the central repository, and includes the author’s
    name and commit message(s).

    For “How to Write a Good Commit Message” see https://chris.beams.io/posts/git-commit/

    You will need to have cloned the FLTK repo but you don’t need to be a GitHub user
    with two-factor-authentication and related security apps and codes unless you wish.

    a. Make sure that your repo is up-to-date (i.e. “git checkout master ; git pull” )
    b, Create and check out a working branch (i.e. “git checkout -b working” )
    c. Edit the code, test and commit your changes
    d. Create patch file(s) using “git format-patch master..”
        Note the trailing “..” so the last argument is “master dot dot” but no spaces.

    This will create one or more patch files named “nnnn-Commit-Message-Title.patch”
    where “nnnn” is a sequence number. The patch files can be submitted as above.

    If the central repository changes you can download the latest version and re-generate
    your patch files with a relatively small amount of work:

    e. Make sure your repo is up-to-date (i.e. “git checkout master ; git pull” )
    f. Check out your working branch again (i.e. “git checkout working” )
    g. Rebase your changes (i.e. “git rebase master”)
        Your changes now appear to be based on the most recent version
    h. Create the patch file(s) using “git format-patch master..” and submit as before.

    To clean up your local repo when the patch has been accepted (or maybe rejected!)

    i. Switch back to the main branch (i.e. “git checkout master”)
    j. Delete the obsolete working branch (i.e. “git branch -D working”)


3. Creating your own FLTK fork on GitHub and submitting a pull request.

    This method involves the most up-front investment by the contributor, and a slightly
    different workflow than you might be familiar with using git in a local development team,
    but GitHub provides extra features to improve your git experience and productivity.

    First of all, go to https://github.com/fltk/fltk and create an account and fork FLTK
    to create your own “public” copy of the FLTK repository, but still on GitHub servers.
    Next you need to clone your GitHub fork to create a “private” local working repo.

    You can pull from the official FLTK repository, but you can’t push to it, no way, no how,
    unless you are a full FLTK developer. And because of changes to GitHub policy in 2021
    you can no longer push to your “public” GitHub form with only username and password.
    Whether you choose to clone via HTTPS or SSH has consequences as discussed later.

    When you clone your GitHub fork from the official FLTK repository, your fork’s “origin”
    will be the official FLTK repository, and while you can login to the GitHub site and click
    “Fetch upstream” to keep your fork in sync, I don’t think you can resolve conflicts, etc.
    Therefore it might be better to add the official FLTK repository as a remote to your local
    repo, in addition to the “origin” that points to your GitHub fork, so you can work locally.

    In your local repo, keep the master branch in sync with the official FLTK repository:

        git remote add fltk https://github.com/fltk/fltk.git
        git checkout master
        git pull fltk master        # your local repo/master is in sync with FLTK
                            # resolve any conflicts in your local repo!
        git push origin master    # your GitHub fork/master is in sync with FLTK

    Any development work you do in your local repo should be on a working branch:

        git checkout master
        git checkout -b working
        # edit, commit, rinse and repeat
        git push origin working    # your GitHub fork/working branch has your latest changes

    Login to your account on GitHub, select the working branch, issue a new pull request.

    At this point, the pull request becomes visible to everyone on the main FLTK repository,.
    They can download the branch, test the code, and offer comments to the pull request.
    When everything is agreed, a developer merges the pull request into the master branch.
    Your name and your commit messages should appear in all their glory in the commit log.

    So how does your choice of HTTPS or SHH affect pushing changes to your GitHub fork?

    If you choose HTTPS, you will need to change your GitHub account settings to enable
    two-factor-authentication (2FA) and also generate a personal access token (PAT).

    The first, 2FA, is required to login to your GitHub account on the website, and involves
    either using an app on your smartphone or program on your computer to generate an
    one-time authentication token, or receiving a one-time token via SMS (deprecated).
    I.e. once 2FA is enabled, you need username, password AND one-time token to login.

    The personal access token (PAT) is generated by GitHub when you enable 2FA and
    is used instead of your password when pushing from your local to your GitHub repo.

    WARNING:
        The PAT is only displayed once during the process of enabling 2FA and it is
        IMPERATIVE that you copy it, or write it down before you click “Next”. The
        PAT is used as “the secret” for initialising the one-time authenication system
        and the recovery codes to be used if you lose your smartphone. If you forget
        your PAT, you will need to login to GitHub using your recovery codes, disable
        and re-enable 2FA to create a new PAT (and recovery codes) and of course
        you will need to re-initialise the authentication app using the “new secret”.

    The GitHub documentation describes how to set up 2FA and mentions that there are a
    number of third party [commercial] apps are available to handle one-time authentication,
    such as 1Password, Authy, LastPass Authenticator and Microsoft Authenticator. Other tools
    are available, such as Google Authenticator, and open source tools such as FreeOTP.
    Aegis Authenticator and KeePassXC.

    An important point to note is that you need to be able to store your PAT, your “secret”,
    securely, as well as your recovery codes, in case your smartphone or computer dies.
    Some of the tools above provide central storage on their servers, others allow export to
    local files, which you can copy to secure storage as you want. They all have pros and cons.
    The choice is yours.

[Albrecht Schlosser]

Hi Duncan,

thanks for the article and sorry for the late and incomplete reply, I'm
too busy doing other stuff right now.

The only thing I picked for now is, as it seems to me, a
misunderstanding of the term PAT used by GitHub

On 11/27/21 3:05 AM duncan wrote:
>  The personal access token (PAT) is generated by GitHub when you
> enable 2FA and
>     is used instead of your password when pushing from your local to
> your GitHub repo.

The term "Personal Access Token" (PAT) is used for some kind of
"password" you create on one of the GitHub setup pages for several
purposes (HTTPS or API access). It *can* be used to push your commits to
GitHub via HTTPS but not for 2FA. The PAT is (in my own imagination) a
special "password" for your account, combined with access permissions
which you (as the account owner) assign to it. You can create many PAT's
and assign different permissions.

One of these permissions is called "repo" which enables you to use the
associated PAT as a password together with your username to push commits
to your repo via HTTPS. This seems to be what you primarily need. You
can do this independently of switching your account to 2FA and, as you
wrote elsewhere, this token will be displayed only once. It is stored in
your account, you can disable or remove it, etc.. You can give it a name
(for yourself), set its lifetime or use it as long as you like, IIRC.
GitHub disables such PAT's when they are not used in a year or for some
other reasons. But this is not an issue as long as you can still login
and create a new one.

OTOH, Two Factor Authentication (2AF) uses OTP (One Time Password or
Token) you need to generate every time you need to login. GitHub uses
time based OTP, i.e. TOTP, or you can choose to use your phone with SMS
(but this may be deprecated as you wrote).

Setting up 2FA with TOTP is an entirely different setup process for your
account. During this process you get a "secret" (also shown only once)
which you can store in your TOTP (authenticator) app or elsewhere. As a
special convenience this is shown as a QR code which you can also copy
(screenshot or image copy?) and save elsewhere. This secret, together
with the time delta (30 sec.) and the token length (6) is used to
generate the one time password for each login at GitHub. You will still
need your account password plus the one time token (generated by your
authenticator app or program) to login to your GitHub account.

During this setup process you can also create and save the recovery
codes you were talking about which can be used to login instead of your
password and token if you lose your authenticator app or your phone.

In yet another setup process you can upload your personal (public) SSH
key from a key pair you created. This SSH key pair can then (also) be
used to push commits to the repo by using SSH access (with a
'g...@github.com:...' repo URL) but this is another topic.

[duncan]

thanks for the article and sorry for the late and incomplete reply, I'm
too busy doing other stuff right now.

The only thing I picked for now is, as it seems to me, a
misunderstanding of the term PAT used by GitHub

Thanks for the additional clarification Albrecht. I really appreciate it.

There's a lot of information scattered around about different aspects of

the overall "process", about the PAT, 2FA, 0TP, authentication apps, and

password vaults, but it's not "joined up" into a coherent whole.

That's why I put that article together, to make sure that I had understood

how many of the pieces you actually need, and how they fit together, but

I clearly hadn't grasped everything. Maybe I just had to jump in and try.

Thanks again, especially when you are so busy.

D.

[imacarthur]

On Tuesday, 30 November 2021 at 07:12:42 UTC duncan wrote:

The only thing I picked for now is, as it seems to me, a
misunderstanding of the term PAT used by GitHub

Thanks for the additional clarification Albrecht. I really appreciate it.

There's a lot of information scattered around about different aspects of

the overall "process", about the PAT, 2FA, 0TP, authentication apps, and

password vaults, but it's not "joined up" into a coherent whole.

FWIW (probably not all that much) I think of a PAT as being more like a fancy encryption "cookie" than a password... but that may not be all that useful a mental image either, TBH...

 

[Albrecht Schlosser]

On 11/30/21 8:12 AM duncan wrote:
> Maybe I just had to jump in and try.

Hi Duncan again,

if you really want to jump in and try I suggest to create a personal
access token for HTTPS with "repo" scope. You can do this w/o affecting
your login (2FA) settings - unless GitHub requires you to change that
when creating a PAT. I just did it - it takes only two minutes or less -
and verified that I could push a commit to my FLTK fork
(Albrecht-S/fltk) with this PAT and a HTTPS URL.

Once you're logged in, go to https://github.com/settings/tokens .

Click on "Generate new token", follow the instructions:

- enter a "Note" so you know what it's good for,
- set Expiration time,
- Select scopes  == 'repo'

Finally click on the green button "Generate token".

Then follow the instructions to copy and save the token.

Done.

Now you can use this token instead of the password when you push commits
to your fork.

Note that you will get a notification by mail so you know that an access
token was added to your account.

If you go back to https://github.com/settings/tokens you can see all the
tokens you created and remove them.

[duncan]

if you really want to jump in and try I suggest to create a personal
access token for HTTPS with "repo" scope. You can do this w/o affecting
your login (2FA) settings - unless GitHub requires you to change that
when creating a PAT.

W00t! With your very patient help Albrecht I have now got it sorted out.

Not quite with the grand scheme that I outlined previously, at least for now.

A couple of comments...

I downloaded KeePassXC to run directly on my Mac, because it handles TOTP

and I will ignore Aegis Authenticator for the moment. [I have fat fingers and

am sure I would never be able to reliably type a secure password on my phone!]

Thanks to you clarifying that the PAT is not the same as the 2FA Secret and that

I could therefore set them up independently.

Stage 1: the personal access token

This is now under [GitHub] Settings / Developer settings / Personal Access Tokens

[and not under Account Security with 2FA as shown in older YouTube tutorials].

I generated a new PAT and immediately copied it into KeePassXC for safety.

Then I went to the git command line, pulled from upstream (i.e. fltk/fltk) and then

tried to push to my origin (engelsman/fltk), was prompted for the password/PAT

and it failed! You need to enable both "repo" AND "workflow" when pushing HTTPS.

So, mild panic now as I deleted and regenerated the PAT with "repo" and "workflow"

and the next "git push origin master" also failed! I'm on a Mac and luckily had seen

a more recent YouTube tutorial that mentioned the solution:

$ git credential-osxkeychain erase  # Warning: only for Mac!

host=github.com

protocol=https

[Return twice]

The next "git push origin master" prompted for username and PAT and succeeded.

Phew!

Now for stage 2: Two factor authentication

I went to [GitHub] Settings / Account Security / Enable Two Factor Authentication

and when it presented the QR code for the 2FA Secret, I clicked the option to show

as text, and copied it immediately into KeePassXC for safety, and then went to the

KeePassXC / Entries / TOTP / Set up TOTP option and entered the 2FA Secret there.

Bit hazy on the order here, but I think I generated a TOTP entry and copied it to the

verification field on GitHub and it displayed a list of recovery codes which I printed,

downloaded, and then saved as an attachment in KeePassXC. You then have to

click the "I have saved my recovery codes" button to activate Two-factor authentication.

Back at the Settings / Account security / Recovery options I enabled the Fallback SMS

option and entered my mobile number, and a 6-digit verification code was immediately

sent to my phone which I had to enter on the form to confirm.

Finally, and with some trepidation, I logged out, logged back in, generated a new TOTP

code via KeePassXC / Entries / TOTP, entered it the verification field, and it worked!

Phew again!

Why they have to make this such a confusing and obfuscated process spread over

several settings pages with help pages describing so many options is beyond me.

Maybe I'm just thick as lots of people have forks and have submitted pull requests

and must have got all of this stuff setup correctly.

Thanks for all your help, again.

D.