48

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://stackoverflow.com/a/14528360/6195194)

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.

Community
  • 1
  • 1
Richard Oswald
  • 493
  • 1
  • 5
  • 6
  • Possible duplicate of [How to use git with gnome-keyring integration](https://stackoverflow.com/questions/13385690/how-to-use-git-with-gnome-keyring-integration) – rugk Mar 13 '19 at 14:23
  • Unfortunately git-credential-libsecret (successor to git-credential-gnome-keyring) isn't packaged in Ubuntu. Upstream Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878599 – Colonel Panic May 28 '23 at 07:15

4 Answers4

137

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.

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.

Philippe
  • 3,945
  • 3
  • 38
  • 56
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 3
    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... – José María Dec 31 '16 at 19:04
  • @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. – VonC Dec 31 '16 at 19:25
  • @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. – VonC Dec 31 '16 at 19:47
  • 18
    After this when using git I get `** (process:18000): CRITICAL **: could not connect to Secret Service: Cannot autolaunch D-Bus without X11 $DISPLAY` – clankill3r Mar 05 '17 at 18:12
  • @clankill3r What OS are you using, with which version of Git? – VonC Mar 05 '17 at 18:18
  • git 2.1.4 on raspbian jessie. Anyway, I reinstalled OS and switched to using SSH. – clankill3r Mar 05 '17 at 20:11
  • 3
    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: https://unix.stackexchange.com/questions/33617/how-can-i-update-to-a-newer-version-of-git-using-apt-get – Lavamantis May 02 '17 at 21:49
  • 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`. – mati865 Jul 15 '17 at 21:21
  • @mati865 Thank you. I have included your comment in the answer for more visibility. – VonC Jul 16 '17 at 04:16
  • I need to retype creds after some time :( – rofrol Oct 06 '17 at 10:41
  • @rofrol there must be some expiration time associated to libsecret. I am not too familiar with it. – VonC Oct 06 '17 at 14:14
  • 1
    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` – sh37211 Sep 14 '18 at 14:12
  • @sh37211 what version of Git are you using? – VonC Sep 14 '18 at 14:17
  • @VonC git version 2.7.4. "git is already the newest version (1:2.7.4-0ubuntu1.4)." – sh37211 Sep 14 '18 at 14:32
  • @M.Abulsoud It would be better to ask a new question, describing your exact OS version, Git version and error message. – VonC Oct 23 '18 at 06:45
  • Worked fine for me, Ubuntu 19.04 – rogerdpack Jul 05 '19 at 07:59
  • `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. – Snake Oct 22 '19 at 00:02
  • @St Yes, libsecret alone (https://developer.gnome.org/libsecret/) should most certainly *not* leave anything in clear-text anywhere. – VonC Oct 22 '19 at 06:26
  • @VonC 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. – Snake Oct 23 '19 at 04:07
  • **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](https://discussion.fedoraproject.org/t/attention-git-credential-libsecret-for-storing-git-passwords-in-the-gnome-keyring-is-now-an-extra-package/18275?u=rugk). – rugk Mar 22 '20 at 15:10
  • @rugk Thank you for this feedback. I have included your comment in the answer for more visibility. – VonC Mar 22 '20 at 16:49
  • 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. – rugk Mar 23 '20 at 14:21
  • @rugk OK, thank you. I have edited the answer accordingly. – VonC Mar 23 '20 at 14:23
  • 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. – Martini Bianco Aug 11 '20 at 12:09
  • @MartiniBianco Then try and change the `credential.helper` settings to `manager-core`. You can install it there: https://github.com/microsoft/git-credential-manager-core. It is Cross-platform... but support on Linux is still lacking. Are you using WSL? (as in https://github.com/Versent/saml2aws/issues/332#issuecomment-660357379) – VonC Aug 11 '20 at 12:15
  • @MartiniBianco Would installing gpg2 and pass be enough? (https://stackoverflow.com/a/52872140/6309) – VonC Aug 11 '20 at 12:21
  • @VonC 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. – Martini Bianco Aug 13 '20 at 13:38
  • @MartiniBianco OK, let me know if you find a solution and write that program. I am interested! – VonC Aug 13 '20 at 13:59
  • @MartiniBianco , @JoséMaría , @clankill3r 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. – bogec Apr 23 '21 at 11:56
  • @VonC 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? – agent18 May 04 '21 at 17:52
  • 1
    @agent18 more than one secret? a libsecret manages a map of : a new secret is just one more entry in this map. – VonC May 04 '21 at 17:56
  • @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? – agent18 May 04 '21 at 18:01
  • @agent18 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" – VonC May 04 '21 at 18:26
  • @VonC 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. – agent18 May 04 '21 at 19:02
  • @agent18 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. – VonC May 04 '21 at 19:35
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/231990/discussion-between-agent18-and-vonc). – agent18 May 05 '21 at 15:57
  • PLEASE PLEASE PLEASE do NOT do this!!! sudo make is dangerous and posts like this should be purged with fire. – Paul Childs Mar 11 '22 at 03:34
  • 1
    @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`. – VonC Mar 11 '22 at 07:49
  • What if we did do `sudo make` ? What's wrong and how to fix it? Thanks. – Myoch May 25 '23 at 08:55
  • @Myoch I would simply re-do the make, without sudo. That way, nothing is created as root. – VonC May 25 '23 at 20:44
9

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

Matthieu Moy
  • 15,151
  • 5
  • 38
  • 65
4

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
CodeWizard
  • 128,036
  • 21
  • 144
  • 167
  • 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! – Richard Oswald Apr 18 '16 at 15:22
0

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

Colonel Panic
  • 132,665
  • 89
  • 401
  • 465