Error when using Git credential helper with gnome-keyring as Sudo

Question

I was looking for a way to store credentials securely while connecting to our Git server which uses SSL. I came across this suggestion by @james-ward (only edit I made was I updated our "system" config instead of our "global" config for Git (https://mcmap.net/q/13472/-how-to-use-git-with-gnome-keyring-integration)

sudo apt-get install libgnome-keyring-dev
cd /usr/share/doc/git/contrib/credential/gnome-keyring
sudo make
git config --system credential.helper /usr/share/doc/git/contrib/credential/gnome-keyring/git-credential-gnome-keyring

I then can run

git clone https://ipaddress/git/repo.git

and the credential helper will store my credentials, however when I run the following:

sudo git clone https://ipaddress/git/repo.git testfolder

it give me the following error

** (process:3713): CRITICAL **: Error communicating with gnome-keyring-daemon

I sometimes need to run sudo git clone since sometimes the directory where I need to make a clone requires it. Any help would be appreciated.

Versions I am using: - git version 1.9.1 - Ubuntu Server 14.0.4

Thank you in advance! -Richard O.

Metaphysics

Possible duplicate of How to use git with gnome-keyring integration – Airline

Unfortunately git-credential-libsecret (successor to git-credential-gnome-keyring) isn't packaged in Ubuntu. Upstream Debian issue bugs.debian.org/cgi-bin/bugreport.cgi?bug=878599 – Cobbs

Answer 1

I sometimes need to run sudo git clone since sometimes the directory where I need to make a clone requires it. Any help would be appreciated

The folder in which you try to clone the repository into was created by root so you dont have permission to write or to create folder under it unless you are root (sudo), set the permissions (chmod or chown) and you will be able to clone into the folder.

chmod 755 /path

Teethe

Thank you for your help and that makes a lot of sense. Another requirement forced me to use SSH keys instead of HTTPS so I no longer need to use the git-credential-gnome-keyring. But I did make sure to create a dedicated git account and give them access to create their own repositories in a certain directory without using sudo based on your help and its working great! – Metaphysics

Answer 2

Beside the use of sudo, note that in 2016, libgnome-keyring is specific to GNOME and is now deprecated (since January 2014, actually).

2022 option: git-credential-manager

Microsoft provides a cross-platform credential helper named GCM (Git Credential Manager), which you can install (no need to build it) and configure:

git-credential-manager-core configure

You will need Git 2.27+ to use it.

Q4 2022: GCM is now Git Credential Manager (no more -core)

git-credential-manager configure

You will need Git 2.38.1+ to use it.

---

2016 option: git-credential-libsecret

Git 2.11+ (Q4 2016) included a new credential helper using libsecret.

See commit 87d1353 (09 Oct 2016) by Mantas Mikulėnas (grawity).
^{(Merged by Junio C Hamano -- gitster -- in commit bfe800c, 26 Oct 2016)}

A new credential helper that talks via "libsecret" with implementations of XDG Secret Service API has been added to contrib/credential/.

it uses libsecret which can support other implementations of XDG Secret Service API.

But in 2022, this is no longer needed. See above

---

As noted by mati865 in the comments:

It should be noted that some distros like Arch and Fedora provide helpers available as both binary and source.

• Libsecret binary on Arch: /usr/lib/git-core/git-credential-libsecret, and
• Libsecret binary on Fedora: /usr/libexec/git-core/git-credential-libsecret.

Note: As @rugk adds in the comments, for Fedora and Git v2.25.2-1 or higher, you need to install an extra package with that binary, because it has been split from the main git package:

dnf install git-credential-libsecret

---

Git 2.41 (Q2 2023) clarifies:

See commit 0a3a972, commit 64f1e65, commit de2fb99, commit 048b673, commit 5747c80, commit 71201ab, commit 16b305c (01 May 2023) by Taylor Blau (ttaylorr).
^{(Merged by Junio C Hamano -- gitster -- in commit fbbf60a, 10 May 2023)}

contrib/credential: remove 'gnome-keyring' credential helper

^{Co-authored-by: Jeff King
Signed-off-by: Jeff King
Signed-off-by: Taylor Blau}

libgnome-keyring was deprecated in 2014 (in favor of libsecret), more than nine years ago.

The credential helper implemented using libgnome-keyring has had a small handful of commits since 2013, none of which implemented or changed any functionality.
The last commit to do substantial work in this area was 15f7221 ("contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring", 2013-09-23, Git v1.8.5-rc0 -- merge), just shy of nine years ago.

This credential helper suffers from the same fgets()-related injection attack (using the new "wwwauth[]" feature) as in the previous commit.
Instead of patching it, let's remove this helper as deprecated.

Jann

Tried to use this, first time seemed to work fine, but on consequential boots I get ** (process:774): CRITICAL **: secret_value_get_text: assertion 'value' failed' and it asks me for my github password again... – Forcible

@JoséMaría are you using Git 2.11. I didn't see any commit fixing a bug regarding libsecret for the next GIt 2.12. – Jann

@JoséMaría Then I would suggest to ask a new question with the exact configuration (OS, Git, libsecret versions, ...) in order to examine that issue in more details. – Jann

After this when using git I get ** (process:18000): CRITICAL **: could not connect to Secret Service: Cannot autolaunch D-Bus without X11 $DISPLAY – Terbia

@Terbia What OS are you using, with which version of Git? – Jann

git 2.1.4 on raspbian jessie. Anyway, I reinstalled OS and switched to using SSH. – Terbia

The /usr/share/doc/git/contrib/credential/libsecret directory won't exist if you have an older version of git. If it's ok to update git, on Ubuntu this worked to get it: unix.stackexchange.com/questions/33617/… – Janson

It should be noted that some distros like Arch and Fedora provide helpers available as both binary and source. Libsecret binary on Arch: /usr/lib/git-core/git-credential-libsecret and on Fedora: /usr/libexec/git-core/git-credential-libsecret. – Mercie

@Mercie Thank you. I have included your comment in the answer for more visibility. – Jann

I need to retype creds after some time :( – Lobule

@Lobule there must be some expiration time associated to libsecret. I am not too familiar with it. – Jann

Re. point 2 above: After installing libsecret et all with apt-get as in point 1 above, on Unbuntu 16.04, there is no libsecret directory in contrib: $ ls /usr/share/doc/git/contrib/credential gnome-keyring netrc osxkeychain wincred – Wertz

@Wertz what version of Git are you using? – Jann

@Jann git version 2.7.4. "git is already the newest version (1:2.7.4-0ubuntu1.4)." – Wertz

@M.Abulsoud It would be better to ask a new question, describing your exact OS version, Git version and error message. – Jann

Worked fine for me, Ubuntu 19.04 – Kathrynkathryne

libsecret still generates ~/.git-credentials with the password in plaintext after Git commands such as git pull. Is this normal? I thought this new method was supposed to be more secure than using git config credential.helper store. This is with Git 2.20.1 and Ubuntu 19.10. – Herpes

@St Yes, libsecret alone (developer.gnome.org/libsecret) should most certainly not leave anything in clear-text anywhere. – Jann

@Jann Thanks, you are right. I found out the problem was that my project directory still contained helper = store in .git/config, which was overriding the global setting. – Herpes

Attention Fedora users: Starting with v2.25.2-1 of git, Fedora now has git-credential-libsecret in an extra package, i.e. you now need to do a dnf install git-credential-libsecret manually to get that binary. More information in detail here. – Airline

@Airline Thank you for this feedback. I have included your comment in the answer for more visibility. – Jann

Nah, you included it in the wrong section. Put it down to "It should be noted that some distros like Arch and Fedora provide helpers available as both binary and source." This is the finished binary, not something you need for development/compiling it by yourself. – Airline

@Airline OK, thank you. I have edited the answer accordingly. – Jann

If I do it this way, everytime I try to fetch or push, I get asked my credentials. Then this message appears: "CRITICAL **: store failed: Cannot create an item in a locked collection" - I couldn't find anything regarding this error. – Echolalia

@MartiniBianco Then try and change the credential.helper settings to manager-core. You can install it there: github.com/microsoft/git-credential-manager-core. It is Cross-platform... but support on Linux is still lacking. Are you using WSL? (as in github.com/Versent/saml2aws/issues/332#issuecomment-660357379) – Jann

@MartiniBianco Would installing gpg2 and pass be enough? (https://mcmap.net/q/13727/-cannot-login-to-docker-account) – Jann

@Jann I have an Ubuntu installation in a Hyper-V virtual machine (not WSL). installing gpg2 and pass didn't change anything. As far as I understand the problem, libsecret tries to save the credential in a collection, which is locked. I don't know enough about this to understand everything. There seems to be no way of manipulating the collections directly. I think I have to write a program for that. For now I use cache and always enter credentials if necessary. – Echolalia

@MartiniBianco OK, let me know if you find a solution and write that program. I am interested! – Jann

@MartiniBianco , @JoséMaría , @Terbia did you try to install gnome-keyring ? Because I was getting similar (** CRITICAL) errors untill I installed the gnome-keyring package on Debian 10 buster. – Rounds

@Jann what do you do when you have more than one secret? how does it work then? My guess, create libsecret2 folder and copy into it the "credential/libsecret" folder and MAKE it? And use this newly created space to store the git password? – Mortie

@Mortie more than one secret? a libsecret manages a map of <key,value>: a new secret is just one more entry in this map. – Jann

@VonC, git-credential-libsecret file contains one key-value pair or multiple key-value pairs. How can I see the structure of it? And how do I add a new key-value pair? Is it just enough to point git config credential helper ... to that file and go about regular business? – Mortie

@Mortie Not sure, which is why I use a credential-manager-core: it wraps whatever vault the underlying OS is using, and allows you to read its values" – Jann

@Jann Thanks. I hereby confirm that it looks like git-credential-libsecret is a file having one secret which I can refer to using git ... credential.helper.... Coming to git-credential-manager-core, I need to install GCM core (somehow) and then provide type of "credential-store" via git config --global credential.credentialStore secretservice (for libsecret) and then what? how do I connect different passwords to where I need them? do you have any link with instructions? (feeling very confused on how to get to the end). Please help me a bit more thanks. – Mortie

@Mortie Simply try and access private repositories: a popup will ask you for your credential the first time, then ask you no more: GCM will have stored your credentials, associated to the remote server, in libsecret. – Jann

Let us continue this discussion in chat. – Mortie

PLEASE PLEASE PLEASE do NOT do this!!! sudo make is dangerous and posts like this should be purged with fire. – Expunction

@PaulChilds Thank you for the feedback. I have remove any sudo xxx trace for this post, and proposed a 2022 option which does not involve sudo make. – Jann

What if we did do sudo make ? What's wrong and how to fix it? Thanks. – Nimbostratus

@Nimbostratus I would simply re-do the make, without sudo. That way, nothing is created as root. – Jann

Answer 3

Using sudo runs the command as root. It's like asking your sysadmin, if you have one, to run a command for you. The root user is not meant to do anything development-related, and therefore git is not meant to be used as root.

Once you run a command as another user (root or any other), it is expected that this other user cannot communicate normally with your usual user (in particular, it doesn't find your gnome-keyring-daemon here).

So, the answer is: "don't do that". If you really need to clone in a particular directory, give yourself permissions on that directory as suggested in CodeWizard's answer. Actually, if you need to clone in a directory where you don't have permission, ask yourself whether you are doing something wrong: in principle, this shouldn't happen (my guess is: you already used sudo too much in the past and this is the reason why you have um-writable directories here and there).

Williamwilliams

Thank you for your comment. Asking yourself "why" you are using sudo is always a good practice to live by. – Metaphysics

Answer 4

Easier: try git-credential-oauth, included in many Linux distributions including Fedora, Debian and Ubuntu.

No more passwords! No more personal access tokens! No more SSH keys!

A Git credential helper that securely authenticates to GitHub, GitLab, BitBucket and other forges using OAuth.

The first time you push, the helper will open a browser window to authenticate. Subsequent pushes within storage lifetime require no interaction.

This is compatible with any storage helper you choose, such as git-credential-cache or git-credential-libsecret (unfortunately not included in Ubuntu).

Cobbs