Conventions around Github (and other?) credentials

[dominykas]

I keep hitting this problem, so I may as well post in here for opinions and possibly some sort of effort on a shared convention.

A bunch of tools we build rely on having access to Github. This implies having a Github token. That's all nice - you put it into a GITHUB_TOKEN (or GH_TOKEN) and off you go. That does not work when you need to access public Github and a Github Enterprise instance - in which case you need at least two tokens.

The approaches I've seen in the wild:

• Provide two tokens via two env vars (e.g. GITHUB_TOKEN and a GITHUB_COM_TOKEN). Renovate takes this approach (although uses different names).
  • The major downsides of this is that the naming can get confusing and it only allows a single non-public GH instance (although I don't know if there's people who regularly access several different GHE instances)
• "Borrow" credentials from other apps, if available. E.g. on macOS you might have git osx keychain credentials helper installed, or you could be using hub, which has credentials stored in ~/.config/hub.
  • It's probably unethical to do that without asking for user permission first, but the UX is great.
• Read from .netrc, e.g. https://github.com/travi/octokit-auth-netrc (not exactly the same as above, as my understanding is that .netrc was meant to be shared between apps?)

A nice tool would probably support all of the above? Are there some other options that I've missed?

[wesleytodd]

Only slightly related, but it might also be helpful if there were best practices or shared approaches we could take for encrypting/decrypting these so they are not just plain text on disk.