git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCHv2 0/13] credential helpers
Date: Wed, 7 Dec 2011 01:42:31 -0500	[thread overview]
Message-ID: <20111207064231.GA499@sigill.intra.peff.net> (raw)
In-Reply-To: <7v7h29fkfy.fsf@alter.siamese.dyndns.org>

On Tue, Dec 06, 2011 at 01:40:17PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> >     ... You can now
> >     do: "git credential-store erase </dev/null" to erase everything
> >     (since you have provided no restrictions, it matches everything).
> 
> That "justification" does not sound so true to me but perhaps that is
> because it is unclear what "erase" means and what it means to give the
> operation parameters.

It's not meant to be a justification, but rather an explanation. I think
the behavior is probably too dangerous to leave.

> When I see "erase $foo", I would find it natural if $foo meant "if there
> is something that matches $foo, then please remove it, but keep everything
> else intact", and not the other way around "Match the existing entries
> against a pattern (or a set of matching patterns) I am giving you, and
> drop all the rest". So if I happen to give you an empty set, I would
> expect nothing is removed.

It does do the first thing you mentioned (you provide one pattern $foo,
and we match the pattern you have given). It's just that the pattern you
have specified is "everything". The problem is not in the matching, but
in the pattern specification language.

This pattern:

  protocol=https
  host=github.com

means "match everything that uses https _and_ has a host of github.com".
The username and path fields are not present, which implicitly means
"don't care about them".

Similarly, this pattern:

  protocol=https

means "match everything that uses https". Everything else is not
specified, and therefore we allow anything.

Then what does the empty pattern do? It cares about nothing, and
therefore matches everything.

By itself, I don't think that is a problem. It's something you might
want to specify, and it's logically consistent with the way the patterns
are matched.  What is dangerous, though, is that failing to provide
input is byte-wise identical to the empty pattern. And that's why I say
it's a pattern specification problem.

A rough BNF for the pattern format is something like:

  pattern = *line
  line = key "=" value
  key = *<any byte except NUL, "=", or "\n">
  value = *<any byte except NUL or "\n">

Because the pattern takes 0 or more lines and no terminator, we can't
distinguish between empty or truncated input and the empty pattern. So
one solution would be:

  pattern = *line "\n"

i.e., require a blank line terminator.

Does that explain the issue better?

-Peff

  reply	other threads:[~2011-12-07  6:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-06  6:21 [PATCHv2 0/13] credential helpers Jeff King
2011-12-06  6:22 ` [PATCHv2 01/13] test-lib: add test_config_global variant Jeff King
2011-12-06  6:22 ` [PATCHv2 02/13] t5550: fix typo Jeff King
2011-12-06  6:22 ` [PATCHv2 03/13] introduce credentials API Jeff King
2011-12-06  6:22 ` [PATCHv2 04/13] credential: add function for parsing url components Jeff King
2011-12-06  6:22 ` [PATCHv2 05/13] http: use credential API to get passwords Jeff King
2011-12-06  6:22 ` [PATCHv2 06/13] credential: apply helper config Jeff King
2011-12-06 23:58   ` Junio C Hamano
2011-12-07  0:45     ` Jeff King
2011-12-07  0:49       ` Jeff King
2011-12-06  6:22 ` [PATCHv2 07/13] credential: add credential.*.username Jeff King
2011-12-06  6:22 ` [PATCHv2 08/13] credential: make relevance of http path configurable Jeff King
2011-12-06  6:22 ` [PATCHv2 09/13] docs: end-user documentation for the credential subsystem Jeff King
2011-12-06  6:22 ` [PATCHv2 10/13] credentials: add "cache" helper Jeff King
2011-12-06  6:23 ` [PATCHv2 11/13] strbuf: add strbuf_add*_urlencode Jeff King
2011-12-06  6:23 ` [PATCHv2 12/13] credentials: add "store" helper Jeff King
2011-12-06 21:50   ` Junio C Hamano
2011-12-09 23:19   ` Jeff King
2011-12-06  6:23 ` [PATCHv2 13/13] t: add test harness for external credential helpers Jeff King
2011-12-06 21:51   ` Junio C Hamano
2011-12-06 22:08     ` Jeff King
2011-12-06 21:40 ` [PATCHv2 0/13] " Junio C Hamano
2011-12-07  6:42   ` Jeff King [this message]
2011-12-08 21:34     ` Junio C Hamano
2011-12-09  2:29       ` Jeff King
2011-12-09 18:00         ` Junio C Hamano
2011-12-09 23:18           ` Jeff King
2011-12-09 23:34             ` Junio C Hamano
2011-12-09 23:39               ` Jeff King
2011-12-09 23:56                 ` 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=20111207064231.GA499@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).