libsecret: sec_free: Assertion `cell->requested > 0' failed

[MartinLoeper]

Which version of GCM are you using?

Credential Manager: 2.0.778+0d6f1c846f (Arch Linux) Linux Kernel: 5.18.7-zen1-1-zen Libsecret: 0.20.5-2

Which Git host provider are you trying to connect to?

• [ ] Azure DevOps
• [ ] Azure DevOps Server (TFS/on-prem)
• [ ] GitHub
• [ ] GitHub Enterprise
• [ ] Bitbucket
• [x] Other - please describe: GitLab self hosted instance

Can you access the remote repository directly in the browser using the remote URL?

• [x] Yes
• [ ] No, I get a permission error
• [ ] No, for a different reason - please describe

---

[Azure DevOps only] What format is your remote URL?

• [x] Not applicable
• [ ] https://dev.azure.com/{org}/...
• [ ] https://{org}@dev.azure.com/{org}/...
• [ ] https://{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.

• [x] Not applicable
• [ ] I only see one identity
• [ ] I checked each identity and none worked

---

Expected behavior

I am authenticated and my Git operation completes successfully.

Actual behavior

An exception is thrown:

OAuth token refresh failed: invalid_grant: The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
info: please complete authentication in your browser...
git-credential-manager-core: ../libsecret/egg/egg-secure-memory.c:596: sec_free: Assertion `cell->requested > 0' failed.
error: /usr/lib/share/git-credential-manager-core/git-credential-manager-core get died of signal 6
remote: HTTP Basic: Access denied

OAuth response shows Authentication successful in the browser though.

Logs

I will attach as soon as it happens again. The error happened multiple times, so I believe it will be thrown again shortly.

[ldennington]

Have you always seen this issue, or did it start to manifest recently? I notice this is not one of our pre-built binary releases. Did you build from source? If so, can you try building a more recent tree?

[MartinLoeper]

Thanks for pointing that out @ldennington!

There are two packages on the AUR:

• https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=git-credential-manager-core
• https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=git-credential-manager-core-bin

I used the former one which builds from source. Now I switched to the latter one to check whether the error still occurs.

[ldennington]

To my knowledge those packages are not maintained by the core GCM maintainers. I would instead install using one of the non-Debian options outlined in the README.

[MartinLoeper]

Yes, I know that, but the second package looks totally okay IMO, because it downloads the binary from this repo, see:

source=("https://github.com/GitCredentialManager/git-credential-manager/releases/download/v$pkgver/gcm-linux_amd64.$pkgver.tar.gz" "$_pkgname.install" 'LICENSE')

from https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=git-credential-manager-core-bin#n21

Effectively, they do the same as the step tar -xvf <path-to-tarball> -C /usr/local/bin in the "non-Debian options outlined in the README" section. I think Arch community members on AUR simply followed the steps from the README.

[MartinLoeper]

Unfortunately the bug still persists in the latest binary distribution from GitHub. I will try to capture more logs with debug flags!

[MartinLoeper]

Update: I found out that the issue comes from using secretservice as credential store. The same exception is thrown when doing git-credential-manager-core diagnose. I changed the credential store to cache for now and set a timeout of 8h using cacheOptions (see: https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/configuration.md#credentialcacheoptions).

Now I do not need to authenticate via web browser every two hours or so. I guess that was the access token (AT) expiration time. Refresh Tokens (RT) should be working as expected now...

I need some more time to figure out why libsecret is throwing the exception.

[Skycoder42]

In #888, I have attached some more logs of the diagnose command with additional information. Maybe that can help. But I too did install gcm via the AUR. I tried both packages, both produce the same error.

[HSAR]

(I've been directed to this issue by the marvellous @mjcheetham) I'm experiencing a similar issue on GCM Core 2.0.785+6074e4e3d3, which I installed with the DEB file from GitHub. I'm on Ubuntu 22.04.01 LTS (bare metal, not VM) and get the following when I connect to BitBucket and git pull, although the initial git clone works completely as expected.

$ git pull
git-credential-manager-core: ../egg/egg-secure-memory.c:596: sec_free: Assertion `cell->requested > 0' failed.
Aborted (core dumped)

Connecting to Gerrit and GitHub works as expected.

[nzbart]

I also experience the same problem on Debian Testing with BitBucket only. git-credential-manager-core diagnose throws the same error:

Running diagnostics...

 [ OK ] Environment
 [ OK ] File system
 [ OK ] Networking
 [ OK ] Git
  >>>>  Credential storagegit-credential-manager-core: ../egg/egg-secure-memory.c:596: sec_free: Assertion `cell->requested > 0' failed.
zsh: IOT instruction  git-credential-manager-core diagnose

Nothing relevant appears in gcm-diagnose.log.

[js6pak]

This issue is caused by GCM freeing the password here https://github.com/GitCredentialManager/git-credential-manager/blob/04631c1f691dfcbce1baa63cfcb55c26375fe598/src/shared/Core/Interop/Linux/SecretServiceCollection.cs#L294

Seems like secret_password_free is supposed to be used only on the results of secret_password_lookup_... apis where they return a duplicated string unlike the currently used secret_value_get which returns the actual data. So it should be safe to just delete that line and the issue is solved.

But what is the reason for searching and unlocking manually instead just using secret_password_lookup_sync?

By the way the SecretService* should probably be freed with g_object_unref

[rstrube]

I'm running into the same issue right now, very frustrating as I can no longer use GCM with my company's Azure Dev Ops Git Repos. Is there an update on when an official fix will land upstream?

[nzbart]

@ldennington thanks for resolving this issue. Would you be able to release the fix for us to use? Currently, dotnet tool has version 2.0.866, which doesn't include this fix.

[ldennington]

@nzbart - the maintainers discussed an out-of-band release this morning, but unfortunately, this issue does not meet the bar because there is a viable workaround. Look for it in our next planned release on February 17.

[nzbart]

@ldennington thanks for the update. By "workaround", do you mean uninstalling git-credential-manager and using something else? Or is there another workaround that means we can continue to use git-credential-manager?

[ldennington]

The workaround I was thinking of is using an alternate credential store for Linux, such as GPG/Pass compatible files or Git's Credential Cache.

[MartinLoeper]

For my colleagues and me git cache works well btw, see: https://github.com/GitCredentialManager/git-credential-manager/issues/793#issuecomment-1270084056. I had to set cacheOptions though.