mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <>
To: M Hickford <>
Cc:, "" <>
Subject: Re: The enduring popularity of git-credential-store
Date: Tue, 8 Nov 2022 22:52:51 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 4005 bytes --]

On 2022-11-08 at 10:50:33, M Hickford wrote:
> Among StackOverflow users [1], git-credential-store appears several
> times more popular than any other credential helper. Does this make
> anyone else uneasy? The docs warn that git-credential-store "stores
> your passwords unencrypted on disk" [2]. Are users sacrificing
> security for convenience?

I definitely think there are better approaches.  However, none of the
credential managers for the three major platforms work without a
desktop environment, so if someone's logging in over SSH, then there's
no more secure option that's going to work for them.  Taylor did
mention GCM, but I believe it has the same problem, and even if it
didn't, it's written in C#, which isn't portable to many Unices and
isn't viable on servers anyway due to dependencies.

Even on Linux desktops, Debian and Ubuntu don't ship the libsecret
credential helper, so users have to build it themselves.

I have written a tool that lets you access credential helpers on your
local machine over an SSH session for trusted machines[0], but it's very

In the ideal world, we'd ship an encrypted store that people could use,
but then we have to deal with export regulations and sanctions and
nobody wants to do that.  We'd also have to deal with multiple
cryptographic libraries for portability and license reasons and nobody
wants to do that, either.

> Firstly, how grave is storing credentials in plaintext? Software
> development guidelines such as CWE discourage storing credentials in
> plaintext [3]. Password managers in desktop environments, mobile
> operating systems and web browsers typically encrypt passwords on disk
> and guard them behind a master password.

I think there's space for credential managers that operate with major
password managers.  Unfortunately, op (the 1Password CLI) isn't open
source, although LastPass has an open-source CLI.  If Firefox and/or
Chromium can offer command-line functionality to access the password
manager, those could be supported.  Such a tool would probably live
outside of Git's codebase because I think interacting with some of those
tools requires parsing JSON, which we won't want to do in C.

> Secondly, the docs recommend git-credential-cache [2] which ships with
> Git and is equally easy to configure. So why isn't it more popular? My
> hypothesis: while caching works great for passwords typed from memory,
> the combination of caching with personal access tokens has poor
> usability. The unmemorised token is lost when the cache expires, so
> the user has to generate a new token every session. I suspect GitHub's
> 2021 decision to stop accepting passwords [4] may have inadvertently
> pushed users from 'cache' to 'store'.

That may be the case, but I'd much rather people use tokens instead of
passwords because they're much more limited and can easily be revoked
(or can even just expire).  We know that people are very bad about
reusing passwords all over the place, so in the event people do
compromise their credentials, they're substantially more limited.

> Thirdly, why doesn't everyone use SSH keys? Unlike HTTP remotes,
> upfront set-up is necessary to clone a public repo. For users
> unfamiliar with SSH, this set-up may be intimidating. Introducing
> users new to Git to SSH at the same time is a significant cognitive
> load.

SSH keys are also more difficult to make work with multiple accounts,
and judging from my experience on StackOverflow, that's not an uncommon
situation to be in.  I have diligently added entries in the FAQ to cover
this, but in general people don't read it unless specifically directed

I do think SSH keys in general work well for forwarding to other
machines, but in a decent number of corporate environments there are
intercepting proxies so everything has to be HTTP.

brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2022-11-08 22:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 10:50 The enduring popularity of git-credential-store M Hickford
2022-11-08 12:00 ` Michal Suchánek
2022-11-08 15:41 ` Jeff King
2022-11-08 21:03   ` Taylor Blau
2023-02-11  7:11   ` M Hickford
2022-11-08 22:52 ` brian m. carlson [this message]
2022-11-12  2:30   ` M Hickford
2022-11-17 17:17   ` Matthew John Cheetham
2022-11-17 18:51     ` Jeff King
2022-11-17 19:29       ` Lessley Dennington
2022-11-17 20:43         ` Jeff King
2023-05-29  9:53           ` M Hickford
2023-05-28 19:33       ` M Hickford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).