mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Michal Suchánek" <>
To: M Hickford <>
Cc:, "" <>
Subject: Re: The enduring popularity of git-credential-store
Date: Tue, 8 Nov 2022 13:00:24 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


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.



  reply	other threads:[~2022-11-08 12:00 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 [this message]
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
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).