All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Jeff King <peff@peff.net>, Ilya Tretyakov <it@it3xl.ru>,
	"brian m. carlson" <bk2204@github.com>,
	git@vger.kernel.org
Subject: Re: Credential helpers are no longer invoked in case of having sub-folder parts in a repository URL. Since 2.26.1 version
Date: Wed, 22 Apr 2020 02:20:20 +0000	[thread overview]
Message-ID: <20200422022020.GF6465@camp.crustytoothpaste.net> (raw)
In-Reply-To: <20200422012817.GD103469@google.com>

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

On 2020-04-22 at 01:28:17, Jonathan Nieder wrote:
> brian m. carlson wrote:
> > On 2020-04-21 at 22:58:37, Jeff King wrote:
> 
> >> This is unrelated to the recent helper fixes in v2.26.x. Here's a simple
> >> reproduction:
> >>
> >>   url=https://git.example.com/my-proj/my-repo.git
> >>   echo url=$url |
> >>   GIT_TERMINAL_PROMPT=0 \
> >>   ./git \
> >>     -c credential.helper= \
> >>     -c credential.$url.helper='!echo username=foo; echo password=bar;:' \
> >>     credential fill
> >> 
> >> which should print a filled credential (with "foo/bar"), but will fail
> >> with recent versions. It bisects to brian's 46fd7b3900 (credential:
> >> allow wildcard patterns when matching config, 2020-02-20).
> >
> > Yeah, I can reproduce this.  It looks like what's happening is that
> > we're percent-encoding the slash in the paths as %2f, which of course
> > isn't going to match in the urlmatch code.  We probably need to tell the
> > percent encoding function not to encode slashes in this case.
> >
> > I'm testing a patch now and hope to have it on the list a little later
> > this evening.  Thanks for reporting and bisecting, and sorry for the
> > breakage.
> 
> Thanks.  Here's another (though I haven't tried bisecting yet):
> 
> 	echo url='https://github.com/git/git' |
> 	GIT_TERMINAL_PROMPT=0 \
> 	git -c credential.helper= \
> 		-c credential.github.com.helper='!echo username=foo; echo password=bar;:' \
> 		credential fill

gitcredentials(7) says the following:

  Git considers each credential to have a context defined by a URL.
  This context is used to look up context-specific configuration, and is
  passed to any helpers, which may use it as an index into secure
  storage.

I'm not sure a hostname qualifies as a URL in this case.  So while my
patch did break this, I don't believe it's ever been documented to
actually work and was an artifact of our implementation (along with
"credential./git/git.helper" and "credential.https://.helper").  I've
also never seen this syntax used in the wild, but maybe I'm not looking
in the right places.

I don't think we can shoehorn it into urlmatch, since that would break
compatibility with the `http.*` config options, so I think we'd have to
revert the entire feature if we want to preserve it.  I think I'd prefer
to leave things as it is since it seems uncommon and there are easy
alternatives, but if folks prefer, I can send a patch to revert the
urlmatch feature.

I will likely not be online tomorrow (Wednesday), so if folks decide
they want a revert, I can send that out Thursday afternoon (GMT-05:00).
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

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

  parent reply	other threads:[~2020-04-22  2:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21 22:31 Credential helpers are no longer invoked in case of having sub-folder parts in a repository URL. Since 2.26.1 version Ilya Tretyakov
2020-04-21 22:58 ` Jeff King
2020-04-22  1:09   ` brian m. carlson
2020-04-22  1:28     ` Jonathan Nieder
2020-04-22  1:36       ` Jeff King
2020-04-22  2:20       ` brian m. carlson [this message]
2020-04-22  4:06         ` Jeff King
2020-04-22 19:20           ` Johannes Schindelin
2020-04-22  1:23   ` [PATCH] credential: fix matching URLs with multiple levels in path brian m. carlson
2020-04-22  4:16     ` Jeff King
2020-04-22 18:45       ` brian m. carlson
2020-04-22 19:51   ` [PATCH v2] " brian m. carlson
2020-04-22 20:04     ` Jeff King
2020-04-24  4:50     ` Carlo Marcelo Arenas Belón
2020-04-24 20:20       ` Junio C Hamano
2020-04-25 21:32   ` [PATCH v3] redential: " brian m. carlson
2020-04-26  1:51     ` Eric Sunshine
2020-04-26 17:26   ` [PATCH v4] credential: " brian m. carlson
2020-04-27  1:18   ` [PATCH v5] " brian m. carlson
2020-04-27 18:44     ` Junio C Hamano

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=20200422022020.GF6465@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=bk2204@github.com \
    --cc=git@vger.kernel.org \
    --cc=it@it3xl.ru \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.