When using the Secret Service credential store, if the keyring is locked at the time when I run a Git operation then GCM deletes the credential from the keyring and fails to authenticate with the remote #694
Assignees
Labels
Comments
16 tasks
|
Thank you for reporting this - I'm planning to investigate next week. In the meantime, the suggested workaround is switching to GPG or plaintext. |
|
Any update on this? We've been struggling with this for weeks but only just found this issue today. |
|
Apologies, no update as of right now. GitHub is off next week, but I will prioritize this item when we return (the week of July 11th). |
|
@ldennington thanks so much for the update! Any idea about an ETA for this yet, or too soon to say? |
|
@slapbox - thanks for the reminder! I've just finished up another project so will make this top priority today. |
|
@slapbox - would you mind sending the contents of your global Git config file? I'm wondering if something there is the issue. On my end, I've set up Secret Service on my Fedora VM and manually locked the keyring. However, whenever I attempt to interact with my remote repository, I enter my keyring password and the credential is not erased. The command proceeds as expected. My trace logs: |
|
Thanks for the follow-up @ldennington! The file looks like this on my machine: I wonder if that blank line for Oddly, when the keyring is unlocked automatically at startup it doesn't necessarily preclude the possibility of this issue occurring. But then closing and re-opening (locking and unlocking) the keyring manually seems to prevent the issue. It seems like there's some other factor in the issue that I'm not understanding yet. Edit: And actually, I just discovered that, at least in this attempt, when I exited out of the GCM window that asks you to sign into Github and try |
|
Thanks for sharing @slapbox! The blank line is actually ok - see the third paragraph of this section on credential helpers for details. Overall, that config looks ok to me. If I'm understanding correctly, the reason I wasn't able to repro is that I was manually locking the key ring? That's super interesting. Also super interesting that it succeeds on the second try. I still think this is an issue with either Git or GCM and will continue to investigate. |
|
Thanks for investigating this and for that link on credential helpers!
I don't know if that's accurate, because my first attempt to workaround this issue was to set the wallet manager appear at login to remind me to manually unlock before running |
|
Today when I ran
Then when I ran it again GCM popped up. When I exited GCM using the X at the top-right of the window the console shows this message, and then immediately proceeds to
After cancelling the dialog, it seems that it just works. I'm increasingly convinced this is some sort of workflow bug, not a loss of credentials, because certainly the credentials were still stored as the pull succeeded. It seems like GCM doesn't know it has the credentials though. Edit: When running |
|
I've been running into the same problem for a long while, finally found the time to figure out what it is and found this issue, yay 😄 I don't know if it's of any help but here's the output I'm getting:
|
|
I looked a bit more into this and it appears that the problem is related to libsecret having a different format of keys and values in the hashtable when unlocking for the first time since the beginning of the user session (and probably also since the last time user's password was changed if that happened more recently). Here's the output I got by adding some debugging prints (see commit: Jackenmen@d6b8e58) for the While this is how it should look: I'm unsure which libsecret or gnome keyring issue exactly is the cause here, there are several potential candidates to choose from:
There's also a possibly related bug report in Chromium which has a workaround implemented here: |
|
Also encountering this: Not sure what I can provide here that will make this useful. I have value-wise a pretty standard setup: ~/.gitconfig System data |
fatso83
added a commit
to fatso83/git-credential-manager
that referenced
this issue
Jan 31, 2023
|
@ldennington #996 fixes the assertion error, not this issue (and this issue is what comment in #1080 mentions), does it? The deletion of the credential, as described in the issue description (and perhaps described in a bit more detail in my recent comments: #694 (comment)) doesn't seem to be caused by that assertion error as the program continues to run, it just decides to delete the credential out of the blue. |
|
@Jackenmen - I did not say that #996 fixed this issue (but rather, the issue described by @fatso83) and left this issue open for precisely that reason. |
|
That's fair, though I would argue he did not provide enough information to know what actually is his issue 😄 He only showed the output of the diagnose command which doesn't really tell us what issue he is running into while actually using GCM rather than its diagnose command. But I admit I thought you referred to #1080 PR, not what he said here, sorry. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Which version of GCM are you using?
Git Credential Manager version 2.0.696+4365b917da (Ubuntu 20.04.4 LTS on VirtualBox, almost fresh installation)
As per your instructions https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md I instructed GCM to use the freedesktop.org Secret Service API as its credential store.
This is how I set up GCM to test the issue described here:
After the last command, as expected, I had to log in into Github and a keyring was created holding the credentials to my Github account.
Problems described below start when the keyring gets locked (eg because I reboot the system; note that the login keyring does not get unlocked on login if the system is set to automatic login, without having to enter the password).
Which Git host provider are you trying to connect to?
Can you access the remote repository directly in the browser using the remote URL?
[Azure DevOps only] What format is your remote URL?
{org}@dev.azure.com/{org}/...{org}.visualstudio.com/...[Azure DevOps only] If the account picker shows more than one identity as you authenticate, check that you selected the same one that has access on the web.
Expected behavior
If the keyring that holds the credentials to my Github account is locked at the time when GCM needs to access it then a popup shows asking me to enter the password to unlock this keyring. When I enter the correct password I am authenticated and my Git operation completes succesfully. The credential is not deleted.
Actual behavior
If the keyring that holds the credentials to my Github account is locked at the time when GCM needs to access it then a popup shows asking me to enter the password to unlock this keyring. When I enter the correct password the keyring gets unlocked, however, the credential is immediately deleted from this keyring and my Git operation fails with the following error:
That the credential is deleted from the keyring can be confirmed by launching the Passwords and Keys tool in ubuntu and keeping it open next to the terminal emulator. If
git pushis then run in the terminal emulator and the correct password is entered into the popup then this is what happens in the Passwords and Keys window: the keyring is unlocked, the credential to my Github account is shown very briefly but then soon removed and the message 'It looks like this collection is empty' is shown.Subsequent attempts to run the Git operation launch the browser and ask me to log into my Github account; when this is done the credential is saved to the keyring and everything works fine until the next time when the keyring is locked when GCM needs to access it.
If, at the time when GCM needs to access the keyring it is not locked then the problem described above does not happen. Instead, at that situation, as expected, I am authenticated, my Git operation completes succesfully and no credentials are deleted from the keyring.
Logs
The text was updated successfully, but these errors were encountered: