Open 3f6a opened 7 months ago
Any updates here?
this is so stupid, even git has integrated credential manager with it's DPAPI
✓ Authentication complete. - gh config set -h github.com git_protocol https ✓ Configured git protocol ! Authentication credentials saved in plain text ✓ Logged in as b4shful
what the fuck
This should not be the default, in fact there's an --insecure-storage
flag for the people who want to save in plaintext. I'd say that if it can't use the keyring for some reason, it should error out and tell the user what went wrong.
Under no circumstances should it save a token in plaintext when the user hasn't asked for this.
@williammartin Is there anything in the works about this?
I have seen this happen to a lot of people (including myself) time and time again.
Oftentimes people are trying to do the right thing, they install and set up a keyring/credential store and even point github cli to it, and then they run gh auth login
again, only to be told the credentials were saved in plain text.
Then it becomes a frantic search for where the credentials got saved to delete the insecure config file.
I'd argue that the default behaviour should NEVER be to save in plain text, the presence of the --insecure-storage
flag should be the ONLY reason that credentials/tokens get saved in plain text. If gh-cli can't work with the keyring/cred store, then it should error out and give the user some information so they could perhaps fix it. Because right now it's very difficult to figure out what's going wrong, and this in turn makes it difficult to use GH CLI with proper credential security.
(also PS: apologies, please excuse my swearing in the previous comment - it was my genuine reaction upon seeing that CLI message. Although given the times we live in, perhaps this reaction to security issues is justified!)
Hihihi.
Firstly, @3f6a, I'm sorry about this going unanswered, there was an extended period where we were dealing with a lot of team churn, and some things got lost. In terms of your original question, we try to use the credential manager as provided over dbus by the zalando go-keyring module. Right now I have no idea why your keyring isn't being used because unfortunately, if there is an error it suppressed and we move on to insecure storage. Why do we do that? Well it relates to:
what the fuck
So just a little history before we figure out what to do next: Originally, the GitHub CLI only supported writing the token insecurely to a file. In fact it was only February 2023 that gh
began using keyrings for secure storage. When this was added, it was opt-in via --secure-storage
because the team didn't want to break existing workflows. Later, this was made the default and the previous insecure behaviour was opt in via --insecure-storage
. The fallback behaviour remained in place however, for the interactive flow we can debate that value of that (it might even be negative), for the non-interactive flow (i.e. --with-token
), no longer falling back is a breaking change.
So, hopefully with that context you can understand why the situation is as it is.
It's don't think it's acceptable to break scripts out there that are calling gh auth login --with-token
on environments that don't have a keyring available. However, we can consider some mitigations and nudges:
--no-insecure-fallback
option for users who really really don't want this to happenno_insecure_fallback
config option for gh config
that makes it persistentWith the interactive flows we have a bit more flexibility around changing behaviour. I think there are three paths we could take here, each with a different tradeoff of safety vs convenience.
--no-insecure-fallback/no_insecure_fallback
idea from above
As above, we could allow users to opt-in to turning this off. The downside of course is that this is opt-in, which even with the warning, still ends up with your token potentially being written to disk.
Re-prompt
On a failure to use the keyring we could offer a prompt along the lines of:
Failed to save the token securely due to <>
Would you like to continue with insecure storage (y/N) ?
This is informative and allows for immediate recovery, which is nice since the user has probably gone through a whole oauth dance already.
Error
On a failure to use the keyring we could error out with the reason.
This might be immediately annoying to a user, but it's a pretty big nudge that they need to start using --insecure-storage
from now on, which should be high friction.
I think I would probably favour all the non-interactive options, and the last of the interactive options (erroring).
Both the re-prompt and error options would also help provide clarity to why keyring operations are failing, since the error is currently suppressed. This isn't the first time this has happened, I vaguely recall creating a branch specifically for someone to get this debug info, which is super lame.
It is pretty late here so I definitely need to sleep on this, and get input from the rest of the team. What do you think though?
Hi @williammartin thanks for this!
I've went down a rabbit hole... on my personal machine, I run a window manager (Hyprland) which needs some prior configuration, but does work with GNOME Keyring. I've gotten used to that one, it can be hard to tell when it's configured right but I've done it enough to know by now.
However, the environment I'm currently working on, a headless Ubuntu 24.04 Server, is just running through a tty, no display manager, no desktop environment, and oh boy has it been a PAIN. I can't for the life of me get GNOME Keyring to work for a series of incredibly dumb reasons and despite even dumber workarounds.
zalando/go-keyring's README says:
It's expected that the default collection login exists in the keyring, because it's the default in most distros. If it doesn't exist, you can create it through the keyring frontend program Seahorse.
It's the default in most desktop environments, and most of them use GNOME Keyring, the ones that don't probably have no choice but to do things GNOME's way. And what about when you're not using a desktop environment?
Seriously though, even if you get GNOME Keyring working on a headless install, it won't create the default login
keyring, and the reason why is (I wish I was kidding) it tries to use GNOME's prompter service for a password prompt, even if you give it the password via stdin! You also can't really manually create it either, as the only working way seems to be Seahorse, which is a GUI app.
It seems like a cascading series of decisions (go-keyring needing secret service (doable) and the login keyring (less doable), and GNOME Keyring being unusable on a proper headless (tty) install) which end up combining in an unfortunate way to make it impossible without a graphical environment. It's quite ironic considering the prevalence of headless and DE-less environments using git and gh.
I see the tricky situation you guys have here, I will come back to this with more input later, but for now it seems I have even more problems. This message is just background information, but it might be somewhat informative and fall under the category of "user input". At a later date I'll come back and give my thoughts specifically on the gh cli side.
It is pretty late here so I definitely need to sleep on this...
Have a wonderful rest, goodnight! <3
For me, back to trying every single org.freedesktop.secrets
provider to see if any of them actually work.
Right now I have no idea why your keyring isn't being used
@williammartin Let me know if there are any tests I can do to give further information !
Note that the Ubuntu servers I'm using have graphical Ubuntu installed, though I connect to them with ssh (without GUI). Also, probably they do not have the latest versions of Ubuntu.
I don’t get you sir
On Fri, 1 Nov 2024 at 21:09 3f6a @.***> wrote:
Right now I have no idea why your keyring isn't being used
@williammartin https://github.com/williammartin Let me know if there are any tests I can do to give further information !
— Reply to this email directly, view it on GitHub https://github.com/cli/cli/issues/8954#issuecomment-2452193565, or unsubscribe https://github.com/notifications/unsubscribe-auth/BMSSCYWDKXYP2YXAQIY2ICLZ6OVCJAVCNFSM6AAAAABGBA2TLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJSGE4TGNJWGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
gh auth login
stores credentials in plain text (at~/.config/gh/hosts.yml
).However, I have keyring installed:
Why aren't the credentials saved in the keyring?
I am on a headless Ubuntu machine, connected remotely by SSH.