The enduring popularity of git-credential-store

The enduring popularity of git-credential-store

[M Hickford]

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?

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.

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

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.

Any ideas how to improve the security of the average Git user?

[1] https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git
 probably as good a survey of non-expert users as we can get
[2] https://git-scm.com/docs/git-credential-store
[3] https://cwe.mitre.org/data/definitions/256.html
[4] https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
[5] https://lore.kernel.org/git/20111210103444.GL16529@sigill.intra.peff.net/t/#u
discussion at introduction of store helper

Re: The enduring popularity of git-credential-store

[Michal Suchánek]

Hello,

On Tue, Nov 08, 2022 at 10:50:33AM +0000, 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?
> 
> 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.
> 
> 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'.
> 
> 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.

I think that basically there is very small user base that could make use
of the provided authentication options in a more secure manner.

The novice users use the simplest option. Using any king of passsword
manager with git is difficult to set up and platform-specific.

The advanced users need automation which in the end means storing the
access credentials in plaitext in one way or another.

If github provides access tokens that can be assigned per-application,
managed, and individually revoked this is probably as good as it gets.
How well the users make use of this feature depends on their security
awareness and requirements.

Thanks

Michal

Re: The enduring popularity of git-credential-store

[Jeff King]

On Tue, Nov 08, 2022 at 10:50:33AM +0000, 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?
> 
> 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.

So obviously credential-store is the least-common-denominator of
storage, and it should (and does) come with a big warning. However, I
wonder if it actually is a reasonable solution for a lot of people:

  - "passwords" these days are often not keys-to-the-kingdom, but
    special-use tokens that allow limited access.

  - the threat model for many people assumes that their local system is
    trusted. Git needs the credential in plaintext at _some_ point. If
    your local user account is compromised, people can read your
    passwords. But they can also trojan Git, etc.

    I do think one is much worse than the other. Stealing a password
    once is easier than installing a malicious Git that records the
    password. And a stolen password can be used many times, as opposed
    to a malicious Git that misbehaves when run by the local user.

So yeah, obviously using a system password store is better if you can.
But it's sometimes difficult to set up, especially when automation is
involved. And I think it buys people less than they might think.
Especially for git's credential helpers, which are meant to be
scriptable, you can just _ask_ them to retrieve the password from the
system store. So they are really only protecting the credentials at
rest. And other approaches, like full-disk encryption, may be enough for
some people.

You asked "does it make anyone else uneasy?". A little, I guess, because
like you I'm sure there are people who are using it only because they
don't know better, and are not heeding the warnings. But it may also be
that some people are using it as a part of a reasoned tradeoff.

So if you're asking "should we stop shipping credential-store", I'm not
_completely_ opposed, but I do wonder if its popularity means it is
better-than-nothing for some folks. If you're asking how we can nudge
people to better systems, that seems like a pure win. But I also don't
know how to do it. ;)

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

Another big problem with credential-cache is that it requires Unix
sockets, so it doesn't run on Windows.

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

Yes, I think it's just that it's too hard to set up. In the early days
of GitHub, people getting confused and flustered by setting up SSH keys
was one of the biggest barriers to adoption (which is the whole reason I
improved the https auth flow, including adding credential helpers).

I do wonder what that's like these days, though. When people could
switch to just using their password from the website, I'm sure it was
much easier than learning about ssh keys. But these days you have to
learn about PATs, etc. I don't know if people do that by hand, or rely
on tools to help (like GitHub Desktop, or probably gh-cli).

> Any ideas how to improve the security of the average Git user?

All of which is to say that I have no clue what the user experience is
like these days, or what drives people in their decision about which
tools to use. ;)

I do stand by credential-store as not being _completely_ without value,
but I also recognize that its existence may cause people to make bad
decisions. If you have a plan, I'm all-ears.

-Peff

Re: The enduring popularity of git-credential-store

[Taylor Blau]

On Tue, Nov 08, 2022 at 10:41:34AM -0500, Jeff King wrote:
> So if you're asking "should we stop shipping credential-store", I'm not
> _completely_ opposed, but I do wonder if its popularity means it is
> better-than-nothing for some folks. If you're asking how we can nudge
> people to better systems, that seems like a pure win. But I also don't
> know how to do it. ;)

GCM is such an alternative, but I don't think it necessarily should ship
in the contrib/ tree. I don't love the idea of a banner nudging people
to use arbitrary software in Git's ordinary output, either.

So, I think my point is that there are easy-to-configure alternatives
out there, and they are certainly worth using over what's in contrib in
certain circumstances, but I, too, don't have a good plan on how to
nudge people to try them out.

Thanks,
Taylor

Re: The enduring popularity of git-credential-store

[brian m. carlson]

[-- 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
preliminary.

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

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.

[0] https://github.com/bk2204/lawn
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

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

Re: The enduring popularity of git-credential-store

[M Hickford]

On Tue, 8 Nov 2022 at 22:52, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> 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.

On my headless Raspberry Pi, I use OAuth access tokens (generated by
GCM) stored in cache with a long timeout. The usability is pretty good
-- once per day I do the OAuth device flow [1] entering a code from
the Raspberry Pi into a device with a web browser [2].

GCM was indeed awkward to install on Linux arm64. I wrote
git-credential-oauth [3][4] in Go to be easier for Linux distros to
package.

[1] https://www.rfc-editor.org/rfc/rfc8628.html

> The OAuth 2.0 device authorization grant is designed for Internet-
> connected devices that either lack a browser to perform a user-agent-
> based authorization or are input constrained to the extent that
> requiring the user to input text in order to authenticate during the
> authorization flow is impractical.  It enables OAuth clients on such
> devices (like smart TVs, media consoles, digital picture frames, and
> printers) to obtain user authorization to access protected resources
> by using a user agent on a separate device.

[2] https://github.com/login/device
[3] https://github.com/hickford/git-credential-oauth
[4] recent thread on git-credential-oauth
https://lore.kernel.org/git/CAGJzqs=+fCQzkDX53H8Mz-DjXicVVgRmmzPjkatSiOpYO7wGGA@mail.gmail.com/T/#u
[5] device flow support for git-credential-oauth
https://github.com/hickford/git-credential-oauth/pull/9

Re: The enduring popularity of git-credential-store

[Matthew John Cheetham]

On 2022-11-08 14:52, brian m. carlson wrote:

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

Not trying to "sell" GCM on the list, but some small corrections re GCM:
GCM today is built on .NET 6 (previously named ".NET Core".. yeah, their
naming sucks :-)) which runs on various Linux distros and FreeBSD (and
Mac and Windows). Althought admitidely not some of the more obscure Unices
like AIX or Solaris..

https://learn.microsoft.com/en-gb/dotnet/core/install/linux

GCM also supports storing credentials securely without a desktop
environment when appropriately configured. On Linux we support at-rest
encryption via GPG, compatible with the `pass` tool (alongside libsecret stores
where we have some plans to try and get working w/o a desktop environment).

https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#gpgpass-compatible-files
https://www.passwordstore.org/

The problem that others have aluded to with GCM and wider Linux availablity
is more a question of supportability of providing pre-built binaries from
our side, not .NET's. GCM is built to link the .NET CLR (the runtime) and is
bundled, so the required deps. are minimal; mainly: glibc, openssl, zlib.

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

One option rather than shipping (or including in contrib/) any of these
credential helpers, could we not reference several other popular helpers
in the docs, and let users make their own choice (but at least some are
then possibly more discoverable)?

>> 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
> there.
> 
> 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.
> 
> [0] https://github.com/bk2204/lawn

There are also enterprises that out-right block the use of SSH (either
techically or as a policy) as they require strict continuous evaluation
of various security policies, on each token use or refresh/re-generation.

Other scenarios I've seen include *per-request/one-time-use* tokens that
are cryptographically bound to the device using hardware security modules.
Not something that SSH is suited for sadly.

Thanks,
Matthew

Re: The enduring popularity of git-credential-store

[Jeff King]

On Thu, Nov 17, 2022 at 09:17:53AM -0800, Matthew John Cheetham wrote:

> > 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.
> 
> One option rather than shipping (or including in contrib/) any of these
> credential helpers, could we not reference several other popular helpers
> in the docs, and let users make their own choice (but at least some are
> then possibly more discoverable)?

I don't have any problem with documenting the options better. The main
reason we have store/cache at all, even though they kind of suck, was to
act as least-common-denominators and pave the way for people making
better helpers. That happened, but nobody ever went back to adjust the
docs.

I do think having the docs say "you should go use X" means that X will
have an advantage over other projects which may compete with it. So I
think we need to be careful to be inclusive of what we'll mention, and
to word it so that we're not endorsing any one project.

-Peff

Re: The enduring popularity of git-credential-store

[Lessley Dennington]

On 11/17/22 10:51 AM, Jeff King wrote:
> I do think having the docs say "you should go use X" means that X will
> have an advantage over other projects which may compete with it. So I
> think we need to be careful to be inclusive of what we'll mention, and
> to word it so that we're not endorsing any one project.
> 
> -Peff

Completely agree with this. I've long wished for a page on git-scm.com 
that's dedicated to (1) explaining what a credential helper is and
(2) offering a list of suggested helpers along with scenarios for which
each is best-suited. This could also be a good place to call out the risks
of using helpers like git-credential-store in a factual, unbiased way.

Thanks,
Lessley

Re: The enduring popularity of git-credential-store

[Jeff King]

On Thu, Nov 17, 2022 at 11:29:35AM -0800, Lessley Dennington wrote:

> On 11/17/22 10:51 AM, Jeff King wrote:
> > I do think having the docs say "you should go use X" means that X will
> > have an advantage over other projects which may compete with it. So I
> > think we need to be careful to be inclusive of what we'll mention, and
> > to word it so that we're not endorsing any one project.
> > 
> > -Peff
> 
> Completely agree with this. I've long wished for a page on git-scm.com
> that's dedicated to (1) explaining what a credential helper is and
> (2) offering a list of suggested helpers along with scenarios for which
> each is best-suited. This could also be a good place to call out the risks
> of using helpers like git-credential-store in a factual, unbiased way.

It's also a nice place because it's easier to keep up-to-date compared
to say, a manpage.

-Peff

Re: The enduring popularity of git-credential-store

[M Hickford]

On Tue, 8 Nov 2022 at 15:41, Jeff King <peff@peff.net> wrote:
>
> On Tue, Nov 08, 2022 at 10:50:33AM +0000, M Hickford wrote:
>
> > 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'.
>
> Another big problem with credential-cache is that it requires Unix
> sockets, so it doesn't run on Windows.

Thanks to the work of Carlo Marcelo Arenas Belón [1], credential-cache
*can* be built on Windows 10 April 2018 update or later. But Git for
Windows has to support older Windows versions for many more years so
the build flag can't be enabled. Perhaps Git for Windows could ship
with a credential-cache binary that works on Windows 10 and gracefully
degrades on older Windows versions? That's beyond my expertise. Help
very welcome at https://github.com/git-for-windows/git/issues/3892

Might this be suitable for a GSoC project? If a mentor could be found.

[1] https://lore.kernel.org/git/20210914072600.11552-1-carenas@gmail.com/

Re: The enduring popularity of git-credential-store

[M Hickford]

On Thu, 17 Nov 2022 at 18:51, Jeff King <peff@peff.net> wrote:
>
> On Thu, Nov 17, 2022 at 09:17:53AM -0800, Matthew John Cheetham wrote:
>
> > > 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.
> >
> > One option rather than shipping (or including in contrib/) any of these
> > credential helpers, could we not reference several other popular helpers
> > in the docs, and let users make their own choice (but at least some are
> > then possibly more discoverable)?
>
> I don't have any problem with documenting the options better. The main
> reason we have store/cache at all, even though they kind of suck, was to
> act as least-common-denominators and pave the way for people making
> better helpers. That happened, but nobody ever went back to adjust the
> docs.
>
> I do think having the docs say "you should go use X" means that X will
> have an advantage over other projects which may compete with it. So I
> think we need to be careful to be inclusive of what we'll mention, and
> to word it so that we're not endorsing any one project.

I agree, although Git for Windows installs Git Credential Manager by
default. Hard to compete with that, but it's fantastic for users.

OAuth credential helpers are so widely useful I think it's worth
introducing them in the documentation. I'll draft a patch.

Re: The enduring popularity of git-credential-store

[M Hickford]

On Thu, 17 Nov 2022 at 20:43, Jeff King <peff@peff.net> wrote:
>
> On Thu, Nov 17, 2022 at 11:29:35AM -0800, Lessley Dennington wrote:
>
> > On 11/17/22 10:51 AM, Jeff King wrote:
> > > I do think having the docs say "you should go use X" means that X will
> > > have an advantage over other projects which may compete with it. So I
> > > think we need to be careful to be inclusive of what we'll mention, and
> > > to word it so that we're not endorsing any one project.
> > >
> > > -Peff
> >
> > Completely agree with this. I've long wished for a page on git-scm.com
> > that's dedicated to (1) explaining what a credential helper is and
> > (2) offering a list of suggested helpers along with scenarios for which
> > each is best-suited. This could also be a good place to call out the risks
> > of using helpers like git-credential-store in a factual, unbiased way.
>
> It's also a nice place because it's easier to keep up-to-date compared
> to say, a manpage.
>
> -Peff

Great idea Lessley! Here's a pull request
https://github.com/git/git-scm.com/pull/1786 to create such a page at
https://git-scm.com/doc/credential-helpers