From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <firstname.lastname@example.org>
Cc: "Eric Sunshine" <email@example.com>,
"Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>,
"Martin Langhoff" <email@example.com>,
"Git Mailing List" <firstname.lastname@example.org>
Subject: Re: [PATCH 3/3] clone: auto-enable git-credential-store when necessary
Date: Mon, 20 May 2019 18:48:47 +0200 (CEST) [thread overview]
Message-ID: <nycvar.QRO.email@example.com> (raw)
On Mon, 20 May 2019, Jeff King wrote:
> On Mon, May 20, 2019 at 07:28:08AM -0400, Eric Sunshine wrote:
> > > The biggest downside is that it's a bit magical from the user's
> > > perspective, because now the password is off in some other file
> > > (usually ~/.git-credentials, but sometimes in $XDG_CONFIG_HOME).
> > > Which complicates things if they want to purge the repo and
> > > password, for example, because now they can't just delete the
> > > repository directory.
> > >
> > > The file location is documented, though, and we point people to the
> > > documentation. So perhaps it will be enough (and better still, may
> > > lead to them configuring a more secure helper).
> > I'm trying to decide how I feel about this based upon my own
> > experience recently of having my password magically stored by Git for
> > Windows without warning or consent on a computer which was not my own
> > but on which I needed to access a private GitHub repository. Although
> > the situation is not perfectly analogous, the concern of having one's
> > password magically squirreled-away _somewhere_ unexpectedly is the
> > same. Being unfamiliar with Git for Windows's credential helper or
> > Windows credential management in general, I experienced more than a
> > few minutes of consternation and alarm before finally figuring out
> > where Git for Windows had stored my password and how to remove it. The
> > sense of alarm and discomfort likely would have not arisen had the
> > credential helper given me the opportunity to approve or deny the
> > action.
> Thanks, that's a good elaboration of the uneasiness I was feeling. This
> patch is better than the status quo in that your password was already
> being squirreled away in plaintext, and now it's at least locked down
> with filesystem permissions. But it's clearly not as far as we could go.
> I was mostly just afraid to break existing workflows, but maybe we
> should be more opinionated.
> Or maybe we just need to give more specific details about how to back
> out the change.
I think that would make the most sense. "If you did not mean for this
password to be stored, call [...]".
> > > +"Note that the password is still stored in plaintext in the filesystem;\n"
> > > +"consider configuring a more secure helper. See \"git help gitcredentials\"\n"
> > > +"and \"git help git-credential-store\" for details.\n"
> > > );
> > Give the above experience, one way to mitigate such feelings of alarm
> > might, at a minimum, be for this message to say where the password is
> > being stored (and, possibly, how to remove it) so the user can do so
> > immediately if desired. Prompting the user to approve or deny the
> > action might also go a long way toward making this more palatable
> > (assuming the session is interactive).
> I actually thought about pointing to the file, but it's non-trivial to
> do so (there's a bunch of internal logic in credential-store to decide
> between $HOME and XDG locations).
> I think what we really need are better commands to manage credentials
> independent of helpers, and then we could recommend a simple command to
> clear a credential that you don't want to have stored. Right now I think
> the best you can do is:
> echo url=https://example.com | git credential reject
> - "reject" is a funny term; this comes from the C code, which thinks
> of it in terms of the server approving/rejecting (and that makes
> sense for scripts calling this command). But at the helper level,
> the operations are really store/erase. We probably ought to support
> those names, too.
> - piping the credential protocol is slightly awkward; we probably
> ought to allow a url on the command line, and avoid reading stdin if
> we get one.
> That would give us:
> git credential erase https://example.com
> which is really quite readable. :)
> Likewise, if we choose not to auto-enable the store helper, we'd
> probably want to give advice on seeding your password. Right now that
> echo url=https://example.com | git credential fill | git credential approve
> which is...not intuitive. It would make sense to me to have a "seed"
> operation which does a fill/approve together. Maybe that should just be
> what "store" does, which would allow:
> $ git credential store https://example.com
> Username for 'https://example.com':
> Password for 'https://firstname.lastname@example.org':
> (Of course you can also just "git fetch" to get prompted, but it seems
> like this shouldn't require a network operation if you don't want it
There is nothing stopping us from adding a new command to `git
credential`: `git credential forget <url>` where the URL may contain the
user name for further differentiation (and maybe even a password that will
be ignored, for copy/pasting convenience).
next prev parent reply other threads:[~2019-05-20 16:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 17:49 Git ransom campaign incident report - May 2019 Martin Langhoff
2019-05-15 18:59 ` Ævar Arnfjörð Bjarmason
2019-05-16 4:27 ` Jeff King
2019-05-17 19:39 ` Johannes Schindelin
2019-05-17 22:20 ` Jeff King
2019-05-17 23:13 ` Martin Langhoff
2019-05-19 5:07 ` Jeff King
2019-05-19 5:10 ` [PATCH 1/3] transport_anonymize_url(): support retaining username Jeff King
2019-05-19 23:28 ` Eric Sunshine
2019-05-20 16:14 ` René Scharfe
2019-05-20 16:36 ` Johannes Schindelin
2019-05-20 16:43 ` Johannes Schindelin
2019-05-19 5:12 ` [PATCH 2/3] clone: avoid storing URL passwords in config Jeff King
2019-05-19 5:16 ` [PATCH 3/3] clone: auto-enable git-credential-store when necessary Jeff King
2019-05-20 11:28 ` Eric Sunshine
2019-05-20 12:31 ` Jeff King
2019-05-20 16:48 ` Johannes Schindelin [this message]
2019-05-20 13:56 ` Ævar Arnfjörð Bjarmason
2019-05-20 14:08 ` Jeff King
2019-05-20 15:17 ` Ævar Arnfjörð Bjarmason
2019-05-20 15:24 ` Jeff King
2019-05-20 17:08 ` Ævar Arnfjörð Bjarmason
2019-05-20 14:43 ` Git ransom campaign incident report - May 2019 Johannes Schindelin
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: http://vger.kernel.org/majordomo-info.html
* 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).