From: Jeff King <peff@peff.net>
To: Bryan Turner <bturner@atlassian.com>
Cc: "O'Connell, Ken" <Ken.O'Connell@cognex.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: credentials are being erased from credential manager via git credential-wincred erase command
Date: Wed, 13 Apr 2016 18:00:54 -0400 [thread overview]
Message-ID: <20160413220054.GB8712@sigill.intra.peff.net> (raw)
In-Reply-To: <CAGyf7-FJcJyP_CdRZLO7Eh6DoWp8XRU2CNczCdaYJO_MS6rnmw@mail.gmail.com>
On Wed, Apr 13, 2016 at 01:12:06PM -0600, Bryan Turner wrote:
> From the credentials code in Git (which I could be mis-reading; I'm
> sure others on the list will correct me if I'm wrong), it appears the
> erase is done after a cached credential is rejected by the server.
> That implies that, periodically, authentication with your Stash server
> is failing and that that failed authentication results in Git clearing
> the "bad" credential. That's likely why you see this happen on
> seemingly random builds.
Yes, that's right. For HTTP, Git will erase the credential only for an
HTTP 401 (or a 407 for the proxy credential). So an intermittent failure
shouldn't cause us to erase the credential there.
But it's possible that a server whose credentials are backed by
something more complicated than a password file (e.g., LDAP or
something) may return a 401 intermittently when the backend process
fails (e.g., connection to the LDAP server fails). And I agree with your
second paragraph (that I snipped) that finding the intermittent failure
is the best first step.
We could potentially teach Git _not_ to erase credentials in such a case
(with a config option). But the downside would be that the user would
then have to manually erase and re-populate the credentials if they do
change.
IMHO, that responsibility really lies with the credential helpers
themselves. Helpers like git-credential-wincred are meant to
transparently cache and update credentials. I think for an automated
process like this, what the user really wants is more like "I'll stick
some credentials in a secure place, and I want Git _only_ to access
them, never update them".
You can hack together something like that today with:
git config credential.helper '!f() {
case "$1" in
get|store) git credential-wincred "$@" ;;
esac
}; f'
and then you can populate it with:
echo url=https://example.com |
git credential fill |
git credential approve
The "fill" will prompt you and generate the proper response to feed to
"approve", which will actually store it in your helper of choice. Or you
can just do a "fetch" from the repository in question, and it will
happen automatically.
If this pattern is something a lot of people want to use, I think we
could wrap that shell snippet into a "git credential-static" or
something that chained to another helper, and you'd configure it like:
git config credential.helper 'static wincred'
or something.
-Peff
prev parent reply other threads:[~2016-04-13 22:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-13 18:49 credentials are being erased from credential manager via git credential-wincred erase command O'Connell, Ken
2016-04-13 19:12 ` Bryan Turner
2016-04-13 22:00 ` Jeff King [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160413220054.GB8712@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Ken.O'Connell@cognex.com \
--cc=bturner@atlassian.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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 NNTP newsgroup(s).