Hub: Obtaining authentication from environment

[pwaller]

I don't want to have a .config/hub file lying around on remote systems where I use hub. I'd prefer to communicate my password through the environment (since I can use ssh SendEnv, etc).

I've tried using GITHUB_USER and GITHUB_PASSWORD with a token generated from https://github.com/settings/applications, but when I try to send a pull request I get "404 not found". It works if I send a pull request by entering my credentials and using .config/hub. Any ideas?

[mislav]

Your use case is not supported right now. The thing about GITHUB_PASSWORD is, it's just an alternative to typing your password in the terminal. hub will still try to exchange those credentials for an OAuth token.

Maybe we could support another variable such as GITHUB_TOKEN, and if it's set, use Basic Auth with your username and that token and never exchange that for OAuth. That would skip reading/writing to ~/.config/hub.

[pwaller]

:+1:

[supermarin]

OSX should support keychain access for this

e.g. https://github.com/nomad/cupertino/blob/master/lib/cupertino/provisioning_portal/commands/login.rb

[mislav]

@mneorr But the keychain client needs to be a compiled program in order to retrieve stuff securely, and I don't wanna go down that road. https://github.com/boxen/boxen/blob/23b0038eda0a67e172fcf6229ea7273ba29ffa18/src/keychain-helper.c

[supermarin]

@mislav not necessary. There's a CLI tool (security) built into OSX. Try man security.

Sample getter for a github token:
security find-generic-password -wgs github.oauth_token

[supermarin]

Setter:
security add-generic-password -a mneorr -s github.oauth_token -w 1234567890abcdefghijklmnoprstuvwxyz

[mislav]

There's a CLI tool (security) built into OSX. Try man security.

…And if you use that route, now any rogue program can shell out and invoke the same command to obtain that password. That defeats the whole purpose of Keychain, as it becomes no more secure than storing it in plain text in a file.

The point of Keychain is that you allow a single binary application to store/retrieve some values. If another app tries to get those values, it will be blocked. If the original binary changes and tries to access those values, Keychain will warn you and ask for approval.

[supermarin]

Well, it's still better than getting your token checked in by accident together with your dotfiles.
~/.config doesn't sound like the right place to store a token.

In my case, fish stores stuff in ~/.config/fish, and that's how I've messed up checking it in.

[supermarin]

Probably add-generic-password isn't the right way but the quickest. After looking a bit more into it, add-internet-password doesn't seem that bad.

$ security add-internet-password                                                                                                                                      Users/musalj
Usage: add-internet-password [-a account] [-s server] [-w password] [options...] [-A|-T appPath] [keychain]
    -a  Specify account name (required)
    -c  Specify item creator (optional four-character code)
    -C  Specify item type (optional four-character code)
    -d  Specify security domain string (optional)
    -D  Specify kind (default is "Internet password")
    -j  Specify comment string (optional)
    -l  Specify label (if omitted, server name is used as default label)
    -p  Specify path string (optional)
    -P  Specify port number (optional)
    -r  Specify protocol (optional four-character SecProtocolType, e.g. "http", "ftp ")
    -s  Specify server name (required)
    -t  Specify authentication type (as a four-character SecAuthenticationType, default is "dflt")
    -w  Specify password to be added
    -A  Allow any application to access this item without warning (insecure, not recommended!)
    -T  Specify an application which may access this item (multiple -T options are allowed)
    -U  Update item if it already exists (if omitted, the item cannot already exist)

[pwaller]

Tidying up my personal issues list, so closing this. Please create a new issue if you're still interested in tracking it.

[mislav]

I would appreciate if you didn't close an old ticket when the issue is still unsolved. Forcing us to open another issue means that we lose the conversation thread as well as everyone who was subscribed to the updates for this issue.

[xakraz]

:+1: also for GITHUB_TOKEN

[parkr]

1c6d4b8cf51fe810fba51e55e485aab4b34ab9f0 c23823db7e07cc81fd3d6a7ec84d4367cc38e218 9e6b7cb1e33dc0a51a706fa57cf0f08a85d0b3b7 (merge commit: 2548707d68032d09b8d3af946668efc4d9a60be3)

[parkr]

Thanks for picking this up, @mislav!

[corysimmons]

I'm not sure this is fixed. I had Hub installed from a while back and just went to try it out again and kept getting 401 errors. Apparently I had deleted my old token. I created a new one and added it, but I'm not sure what permissions that token needs, and it seems like bad design to make the user have to track down all this stuff.

Is it possible to test if the token is good and if it isn't generate/store a new one? Fringe case, I know, but it would've saved me a 10 minute headache. :^)

[mislav]

@corysimmons No updates yet. Pull requests welcome!

[corysimmons]

I would but I don't know Go at all. Planning on learning it in the next few months. Will get back to you then. ;^)

[danielcompton]

I had the same issue today.

~/D/j/karma (master) $ hub fork
Error creating fork: Unauthorized (HTTP 401)
Bad credentials

A few things could make this easier to debug/fix:

• Say where the bad credentials came from (~/.config/hub)
• Say which user Hub was attempting to authenticate as
• Include in the log message that this is a Hub error, not a Git error (maybe?)
• Tell people that they can clear credentials and reauthenticate by deleting ~/.config/hub (or whatever is the correct way of doing this)

[mislav]

@corysimmons I didn't know Go at all as well until @jingweno (then just a fan) rewrote all of hub in Go and I've accepted it as a contribution :wink:

@danielcompton Those are all great suggestions. I would like to implement some of your ideas together with a specialized command to handle (re)authentication. Then, the error message could suggest that you try to reauthenticate to obtain a fresh token.

[corysimmons]

lol what kind of person submits a PR with an entire project rewritten in another language? What kind of person accepts that? You guys are crazy, or talented, or both. :dancers:

[mislav]

lol what kind of person submits a PR with an entire project rewritten in another language? What kind of person accepts that?

Yeah it's pretty crazy, I know. :smile: The Go version was faster (I plateaued in terms of how fast I can make Ruby implementation be) and easier to distribute via prebuilt binaries.

[corysimmons]

Looks great. I'm excited to learn it. =)

[owenthereal]

@calebthompson It's pretty crazy :). I documented why I did that. And @mislav helped a lot for the migration.

[calebthompson]

Uh, hi. @corysimmons maybe?

[corysimmons]

@jingweno Yeah, read it the other day. Seems amazing.

@calebthompson Yeah I think he meant to ping me. =)

[FranciscoBorges]

So originally the argument for not using OSX Keychain was that hub was not compiled. Hub now is written in Go and distributed in compiled form, would it be too difficult to just add Keychain support?

FWIW, I would be using 'hub' in a GitHub Enterprise environment where I must work with tokens, i.e. authenticating with user/pass directly with the GitHub server is never going to work.

[mislav]

@FranciscoBorges I'm thinking of adding support for git credential helper, and then you could configure hub to use git-credential-osxkeychain (ships with git) to store credentials in macOS Keychain. Would that be an acceptable solution? https://github.com/github/hub/issues/1217

[supermarin]

That sounds good to me

[maxkomarychev]

Here's how I managed to marry hub with osx keychain, perhaps will be useful for someone.

I created shell alias for hub that reads token from keychain and provides it as a env variable for hub command.

1. create token with necessary permissions (https://github.com/github/hub/blob/master/share/man/man1/hub.1.md#github-oauth-authentication)
2. copy the token
3. add token into keychain: security add-generic-password -a <your username> -s <service name> -w, for instance: security add-generic-password -a johndoe -s hub -w (you will be prompted twice for the token, just hit cmd+v and hit enter)
4. open ~/.bash_profile with your favorite editor
5. add alias: alias ghub='GITHUB_TOKEN=$(security find-generic-password -s <service> -a <account> -w) hub'
6. reload your shell config: source ~/.bash_profile
7. now you can use hub through alias ghub and it will be authorized with your token :)

[jsravn]

I wonder why hub can't simply read a gpg encrypted file and prompt for the password when opening? Would you be open to a PR to do that? hub is the only tool I use which stores a sensitive key in plaintext format with no encryption. I don't use OS X but I imagine Keychain can handle gpg too.

[mislav]

I wonder why hub can't simply read a gpg encrypted file and prompt for the password when opening? Would you be open to a PR to do that?

@jsravn That would indeed be more secure, but hub will not aim to cover the implementation details of different secure stores. I definitely do not want to handle GPG-anything in hub, since I can already see that maintaining such a thing would quickly consume all my available time (which I don't have, since I'm already struggling to maintain hub as it is). I would rather than we support a single protocol such as git "askpass" or credential helper. Then people can set up their own executable to handle storing credentials in any way that they prefer.

Yes I would be open to PRs that improve security, but in a way that potentially helps the majority of hub users and across different platforms. ✨