search

git-ecosystem / git-credential-manager

Secure, cross-platform Git credential storage with authentication to GitHub, Azure Repos, and other popular Git hosting services.
Other
6.92k stars 1.83k forks source link

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

Open gaazkam opened 2 years ago

gaazkam commented 2 years ago

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:

sudo dpkg -i Downloads/gcmcore-linux_amd64.2.0.696.deb
git-credential-manager-core configure
git config --global user.name gaazkam
git config --global user.email "26407962+gaazkam@users.noreply.github.com"
git config --global credential.credentialStore secretservice
git clone https://github.com/gaazkam/mon.git
cd mon
git push

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?

[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:

remote: No anonymous write access.
fatal: Authentication failed for 'https://github.com/gaazkam/mon.git/'

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 push is 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

m@m-VirtualBox:~$ export GCM_TRACE=1
m@m-VirtualBox:~$ export GIT_TRACE=1
m@m-VirtualBox:~$ cd mon
m@m-VirtualBox:~/mon$ git push
10:27:02.657020 git.c:439               trace: built-in: git push
10:27:02.661387 run-command.c:663       trace: run_command: GIT_DIR=.git git-remote-https origin https://github.com/gaazkam/mon.git
10:27:03.241135 run-command.c:663       trace: run_command: '/usr/local/share/gcm-core/git-credential-manager-core get'
10:27:03.868554 ...re/Application.cs:95 trace: [RunInternalAsync] Version: 2.0.696.25923
10:27:03.872331 ...re/Application.cs:96 trace: [RunInternalAsync] Runtime: .NET 6.0.3
10:27:03.872536 ...re/Application.cs:97 trace: [RunInternalAsync] Platform: Linux (x86-64)
10:27:03.872591 ...re/Application.cs:98 trace: [RunInternalAsync] OSVersion: Linux m-VirtualBox 5.13.0-41-generic #46~20.04.1-Ubuntu SMP Wed Apr 20 13:16:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
10:27:03.873047 ...re/Application.cs:99 trace: [RunInternalAsync] AppPath: /usr/local/share/gcm-core/git-credential-manager-core
10:27:03.873135 ...e/Application.cs:100 trace: [RunInternalAsync] Arguments: get
10:27:04.073771 ...GitCommandBase.cs:33 trace: [ExecuteAsync] Start 'get' command...
10:27:04.096547 ...GitCommandBase.cs:47 trace: [ExecuteAsync] Detecting host provider for input:
10:27:04.099318 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   protocol=https
10:27:04.099456 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   host=github.com
10:27:04.194879 ...viderRegistry.cs:149 trace: [GetProviderAsync] Performing auto-detection of host provider.
10:27:04.202265 ...viderRegistry.cs:158 trace: [GetProviderAsync] Auto-detect probe timeout is 2 ms.
10:27:04.208775 ...viderRegistry.cs:166 trace: [GetProviderAsync] Checking against 4 host providers registered with priority 'Normal'.
10:27:04.213750 ...GitCommandBase.cs:50 trace: [ExecuteAsync] Host provider 'GitHub' was selected.
10:27:04.222221 .../HostProvider.cs:126 trace: [GetCredentialAsync] Looking for existing credential in store with service=https://github.com account=...
10:27:11.296076 .../HostProvider.cs:140 trace: [GetCredentialAsync] Existing credential found.
10:27:11.298580 ...GitCommandBase.cs:54 trace: [ExecuteAsync] End 'get' command...
10:27:11.531683 run-command.c:663       trace: run_command: '/usr/local/share/gcm-core/git-credential-manager-core erase'
10:27:11.837155 ...re/Application.cs:95 trace: [RunInternalAsync] Version: 2.0.696.25923
10:27:11.840275 ...re/Application.cs:96 trace: [RunInternalAsync] Runtime: .NET 6.0.3
10:27:11.840370 ...re/Application.cs:97 trace: [RunInternalAsync] Platform: Linux (x86-64)
10:27:11.840392 ...re/Application.cs:98 trace: [RunInternalAsync] OSVersion: Linux m-VirtualBox 5.13.0-41-generic #46~20.04.1-Ubuntu SMP Wed Apr 20 13:16:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
10:27:11.840565 ...re/Application.cs:99 trace: [RunInternalAsync] AppPath: /usr/local/share/gcm-core/git-credential-manager-core
10:27:11.840636 ...e/Application.cs:100 trace: [RunInternalAsync] Arguments: erase
10:27:11.989844 ...GitCommandBase.cs:33 trace: [ExecuteAsync] Start 'erase' command...
10:27:12.011502 ...GitCommandBase.cs:47 trace: [ExecuteAsync] Detecting host provider for input:
10:27:12.014696 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   protocol=https
10:27:12.014811 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   host=github.com
10:27:12.014864 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   username=
10:27:12.014880 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   password=********
10:27:12.074374 ...viderRegistry.cs:149 trace: [GetProviderAsync] Performing auto-detection of host provider.
10:27:12.080330 ...viderRegistry.cs:158 trace: [GetProviderAsync] Auto-detect probe timeout is 2 ms.
10:27:12.084111 ...viderRegistry.cs:166 trace: [GetProviderAsync] Checking against 4 host providers registered with priority 'Normal'.
10:27:12.086713 ...GitCommandBase.cs:50 trace: [ExecuteAsync] Host provider 'GitHub' was selected.
10:27:12.088833 .../HostProvider.cs:173 trace: [EraseCredentialAsync] Erasing stored credential in store with service=https://github.com account=...
10:27:12.168989 .../HostProvider.cs:176 trace: [EraseCredentialAsync] Credential was successfully erased.
10:27:12.169133 ...GitCommandBase.cs:54 trace: [ExecuteAsync] End 'erase' command...
remote: No anonymous write access.
fatal: Authentication failed for 'https://github.com/gaazkam/mon.git/'
ldennington commented 2 years ago

Thank you for reporting this - I'm planning to investigate next week. In the meantime, the suggested workaround is switching to GPG or plaintext.

Nantris commented 2 years ago

Any update on this? We've been struggling with this for weeks but only just found this issue today.

ldennington commented 2 years ago

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).

Nantris commented 2 years ago

@ldennington thanks so much for the update! Any idea about an ETA for this yet, or too soon to say?

ldennington commented 2 years ago

@Slapbox - thanks for the reminder! I've just finished up another project so will make this top priority today.

ldennington commented 2 years ago

@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:

15:10:33.573455 git.c:458               trace: built-in: git push
15:10:33.573697 run-command.c:654       trace: run_command: GIT_DIR=.git git remote-https origin https://github.com/ldennington/ac_tutorial_cocoapods_second_copy.git
15:10:33.575693 git.c:745               trace: exec: git-remote-https origin https://github.com/ldennington/ac_tutorial_cocoapods_second_copy.git
15:10:33.575776 run-command.c:654       trace: run_command: git-remote-https origin https://github.com/ldennington/ac_tutorial_cocoapods_second_copy.git
15:10:33.782419 run-command.c:654       trace: run_command: '/usr/local/share/gcm-core/git-credential-manager-core get'
15:10:33.917148 ...re/Application.cs:95 trace: [RunInternalAsync] Version: 2.0.788.2530
15:10:33.918392 ...re/Application.cs:96 trace: [RunInternalAsync] Runtime: .NET 6.0.7
15:10:33.918448 ...re/Application.cs:97 trace: [RunInternalAsync] Platform: Linux (x86-64)
15:10:33.918484 ...re/Application.cs:98 trace: [RunInternalAsync] OSVersion: Linux fedora 5.18.10-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 7 17:41:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
15:10:33.918561 ...re/Application.cs:99 trace: [RunInternalAsync] AppPath: /usr/local/share/gcm-core/git-credential-manager-core
15:10:33.918617 ...e/Application.cs:100 trace: [RunInternalAsync] Arguments: get
15:10:33.976313 ...GitCommandBase.cs:33 trace: [ExecuteAsync] Start 'get' command...
15:10:33.988601 ...GitCommandBase.cs:47 trace: [ExecuteAsync] Detecting host provider for input:
15:10:33.989537 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   protocol=https
15:10:33.989608 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   host=github.com
15:10:34.016402 ...viderRegistry.cs:149 trace: [GetProviderAsync] Performing auto-detection of host provider.
15:10:34.019882 ...viderRegistry.cs:162 trace: [GetProviderAsync] Auto-detect probe timeout is 2 ms.
15:10:34.021409 ...viderRegistry.cs:170 trace: [GetProviderAsync] Checking against 4 host providers registered with priority 'Normal'.
15:10:34.022451 ...GitCommandBase.cs:50 trace: [ExecuteAsync] Host provider 'GitHub' was selected.
15:10:34.024278 .../HostProvider.cs:126 trace: [GetCredentialAsync] Looking for existing credential in store with service=https://github.com account=...
15:10:39.823363 .../HostProvider.cs:140 trace: [GetCredentialAsync] Existing credential found.
15:10:39.824316 ...GitCommandBase.cs:54 trace: [ExecuteAsync] End 'get' command...
15:10:39.970213 run-command.c:654       trace: run_command: '/usr/local/share/gcm-core/git-credential-manager-core store'
15:10:40.090069 ...re/Application.cs:95 trace: [RunInternalAsync] Version: 2.0.788.2530
15:10:40.091397 ...re/Application.cs:96 trace: [RunInternalAsync] Runtime: .NET 6.0.7
15:10:40.091454 ...re/Application.cs:97 trace: [RunInternalAsync] Platform: Linux (x86-64)
15:10:40.091490 ...re/Application.cs:98 trace: [RunInternalAsync] OSVersion: Linux fedora 5.18.10-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 7 17:41:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
15:10:40.091568 ...re/Application.cs:99 trace: [RunInternalAsync] AppPath: /usr/local/share/gcm-core/git-credential-manager-core
15:10:40.091626 ...e/Application.cs:100 trace: [RunInternalAsync] Arguments: store
15:10:40.150685 ...GitCommandBase.cs:33 trace: [ExecuteAsync] Start 'store' command...
15:10:40.165253 ...GitCommandBase.cs:47 trace: [ExecuteAsync] Detecting host provider for input:
15:10:40.166472 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   protocol=https
15:10:40.166626 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   host=github.com
15:10:40.166689 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   username=ldennington
15:10:40.166744 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   password=********
15:10:40.196194 ...viderRegistry.cs:149 trace: [GetProviderAsync] Performing auto-detection of host provider.
15:10:40.199527 ...viderRegistry.cs:162 trace: [GetProviderAsync] Auto-detect probe timeout is 2 ms.
15:10:40.201078 ...viderRegistry.cs:170 trace: [GetProviderAsync] Checking against 4 host providers registered with priority 'Normal'.
15:10:40.202124 ...GitCommandBase.cs:50 trace: [ExecuteAsync] Host provider 'GitHub' was selected.
15:10:40.202897 .../HostProvider.cs:160 trace: [StoreCredentialAsync] Storing credential with service=https://github.com account=ldennington...
15:10:40.236043 .../HostProvider.cs:162 trace: [StoreCredentialAsync] Credential was successfully stored.
15:10:40.236154 ...GitCommandBase.cs:54 trace: [ExecuteAsync] End 'store' command...
15:10:40.242426 run-command.c:654       trace: run_command: git send-pack --stateless-rpc --helper-status --thin --progress https://github.com/ldennington/ac_tutorial_cocoapods_second_copy.git/ --stdin
15:10:40.245046 git.c:458               trace: built-in: git send-pack --stateless-rpc --helper-status --thin --progress https://github.com/ldennington/ac_tutorial_cocoapods_second_copy.git/ --stdin
15:10:40.245513 run-command.c:654       trace: run_command: git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset --progress
15:10:40.247064 git.c:458               trace: built-in: git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset --progress
Nantris commented 2 years ago

Thanks for the follow-up @ldennington!

The file looks like this on my machine:

[user]
        email = redacted
        name = redacted
[credential]
        helper = /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret
        helper = 
        helper = /usr/local/share/gcm-core/git-credential-manager-core
        credentialStore = secretservice
[credential "https://dev.azure.com"]
        useHttpPath = true

I wonder if that blank line for helper = might have something to do with it?

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 git pull again, the second time it seems to work as intended, even if I did not enter my credentials anew. Perhaps this is really just a user interface bug? Any thoughts?

ldennington commented 2 years ago

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.

Nantris commented 2 years ago

Thanks for investigating this and for that link on credential helpers!

If I'm understanding correctly, the reason I wasn't able to repro is that I was manually locking the key ring?

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 git pull, and when I did manually unlock, the issue still occurred. I'm not really sure what to make of that finding.

Nantris commented 2 years ago

Today when I ran git pull it first said:

remote: Repository not found. fatal: Authentication failed for ....

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 git pull successfully (without me having to enter git pull again)

fatal: helper error (255): User cancelled dialog.

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 git push a bit later, it pops up the GCM window again. And after exiting it, again the operation completes successfully once the window closes.

Jackenmen commented 1 year ago

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 :smile:

I don't know if it's of any help but here's the output I'm getting:

Jackenmen commented 1 year ago

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: https://github.com/Jackenmen/git-credential-manager/commit/d6b8e58bc090ec1012a60aa29e6f81008f0053b4) for the secretAttrs hashtable:

❯ echo $'protocol=https\nhost=gitlab.com\n' | GIT_TRACE=1 GCM_TRACE=1 out/shared/Git-Credential-Manager/bin/Debug/net6.0/git-credential-manager get
02:57:02.872916 ...re/Application.cs:95 trace: [RunInternalAsync] Version: 2.0.886.47318
02:57:02.879782 ...re/Application.cs:96 trace: [RunInternalAsync] Runtime: .NET 6.0.12
02:57:02.879808 ...re/Application.cs:97 trace: [RunInternalAsync] Platform: Linux (x86-64)
02:57:02.879817 ...re/Application.cs:98 trace: [RunInternalAsync] OSVersion: Linux JakubUbuntu2204PC 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
02:57:02.879877 ...re/Application.cs:99 trace: [RunInternalAsync] AppPath: /home/ubuntu/work/git-credential-manager/out/shared/Git-Credential-Manager/bin/Debug/net6.0/git-credential-manager
02:57:02.879923 ...e/Application.cs:100 trace: [RunInternalAsync] InstallDir: /home/ubuntu/work/git-credential-manager/out/shared/Git-Credential-Manager/bin/Debug/net6.0/
02:57:02.879951 ...e/Application.cs:101 trace: [RunInternalAsync] Arguments: get
02:57:02.930952 ...GitCommandBase.cs:33 trace: [ExecuteAsync] Start 'get' command...
02:57:02.956365 ...GitCommandBase.cs:47 trace: [ExecuteAsync] Detecting host provider for input:
02:57:02.957476 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   protocol=https
02:57:02.957544 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   host=gitlab.com
02:57:02.969298 ...viderRegistry.cs:149 trace: [GetProviderAsync] Performing auto-detection of host provider.
02:57:02.973758 ...viderRegistry.cs:162 trace: [GetProviderAsync] Auto-detect probe timeout is 2 ms.
02:57:02.975676 ...viderRegistry.cs:170 trace: [GetProviderAsync] Checking against 4 host providers registered with priority 'Normal'.
02:57:02.977278 ...GitCommandBase.cs:50 trace: [ExecuteAsync] Host provider 'GitLab' was selected.
secretAttrs['gkr:compat:hashed:xdg:schema'] = ad50fd94b9c5a1d9b5368fb722f1a45a
secretAttrs['gkr:compat:hashed:account'] = da0048d0899c4f123beb9593706b9f14
secretAttrs['gkr:compat:hashed:service'] = 7a85317269127828187572699833fb17
secretAttrs['xdg:schema'] = org.freedesktop.Secret.Generic
02:57:03.085946 ...nds/GetCommand.cs:39 trace: [ExecuteInternalAsync] Writing credentials to output:
02:57:03.086000 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   protocol=https
02:57:03.086033 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   host=gitlab.com
02:57:03.086040 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   username=
02:57:03.086080 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   password=********
protocol=https
host=gitlab.com
username=
password=********

02:57:03.086549 ...GitCommandBase.cs:54 trace: [ExecuteAsync] End 'get' command...

While this is how it should look:

❯ echo $'protocol=https\nhost=gitlab.com\n' | GIT_TRACE=1 GCM_TRACE=1 out/shared/Git-Credential-Manager/bin/Debug/net6.0/git-credential-manager get
03:02:08.344042 ...re/Application.cs:95 trace: [RunInternalAsync] Version: 2.0.886.47318
03:02:08.351866 ...re/Application.cs:96 trace: [RunInternalAsync] Runtime: .NET 6.0.12
03:02:08.351899 ...re/Application.cs:97 trace: [RunInternalAsync] Platform: Linux (x86-64)
03:02:08.351909 ...re/Application.cs:98 trace: [RunInternalAsync] OSVersion: Linux JakubUbuntu2204PC 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
03:02:08.351962 ...re/Application.cs:99 trace: [RunInternalAsync] AppPath: /home/ubuntu/work/git-credential-manager/out/shared/Git-Credential-Manager/bin/Debug/net6.0/git-credential-manager
03:02:08.352007 ...e/Application.cs:100 trace: [RunInternalAsync] InstallDir: /home/ubuntu/work/git-credential-manager/out/shared/Git-Credential-Manager/bin/Debug/net6.0/
03:02:08.352035 ...e/Application.cs:101 trace: [RunInternalAsync] Arguments: get
03:02:08.405271 ...GitCommandBase.cs:33 trace: [ExecuteAsync] Start 'get' command...
03:02:08.419529 ...GitCommandBase.cs:47 trace: [ExecuteAsync] Detecting host provider for input:
03:02:08.420537 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   protocol=https
03:02:08.420571 ...GitCommandBase.cs:48 trace: [ExecuteAsync]   host=gitlab.com
03:02:08.433163 ...viderRegistry.cs:149 trace: [GetProviderAsync] Performing auto-detection of host provider.
03:02:08.438992 ...viderRegistry.cs:162 trace: [GetProviderAsync] Auto-detect probe timeout is 2 ms.
03:02:08.441213 ...viderRegistry.cs:170 trace: [GetProviderAsync] Checking against 4 host providers registered with priority 'Normal'.
03:02:08.443097 ...GitCommandBase.cs:50 trace: [ExecuteAsync] Host provider 'GitLab' was selected.
secretAttrs['account'] = oauth2
secretAttrs['service'] = git:https://gitlab.com
secretAttrs['xdg:schema'] = com.microsoft.GitCredentialManager
03:02:08.494174 ...pClientFactory.cs:58 trace: [CreateClient] Creating new HTTP client instance...
03:02:09.173488 ...nds/GetCommand.cs:39 trace: [ExecuteInternalAsync] Writing credentials to output:
03:02:09.173553 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   protocol=https
03:02:09.173630 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   host=gitlab.com
03:02:09.173839 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   username=oauth2
03:02:09.173957 ...nds/GetCommand.cs:40 trace: [ExecuteInternalAsync]   password=********
protocol=https
host=gitlab.com
username=oauth2
password=********

03:02:09.175356 ...GitCommandBase.cs:54 trace: [ExecuteAsync] End 'get' command...

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: https://bugs.chromium.org/p/chromium/issues/detail?id=660005

fatso83 commented 1 year ago

Also encountering this:

$ LANG=C LC_ALL=C sh -c 'git-credential-manager diagnose'
Running diagnostics...

 [ OK ] Environment
 [ OK ] File system
 [ OK ] Networking
 [ OK ] Git
  >>>>  Credential storagegit-credential-manager: ../egg/egg-secure-memory.c:596: sec_free: Assertion `cell->requested > 0' failed.
Aborted (core dumped)

Not sure what I can provide here that will make this useful. I have value-wise a pretty standard setup:

~/.gitconfig

[credential]
    # One week in-mem caching of HTTPS credentials
    helper = cache --timeout=604800
    credentialStore = secretservice

System data

$  npx envinfo --system

  System:
    OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (12) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
    Memory: 17.87 GB / 31.32 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
ldennington commented 1 year ago

@fatso83 the issue you describe was fixed with #996 and will be released with the next version of GCM (scheduled for Feb. 17).

Jackenmen commented 1 year ago

@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: https://github.com/GitCredentialManager/git-credential-manager/issues/694#issuecomment-1347731369) 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.

ldennington commented 1 year ago

@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.

Jackenmen commented 1 year ago

That's fair, though I would argue he did not provide enough information to know what actually is his issue :smile: 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.