From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] config: reject invalid VAR in 'git -c VAR=VAL command'
Date: Tue, 21 Feb 2017 11:15:52 -0800 [thread overview]
Message-ID: <CAGZ79kbR2QQyYO1dnQ0jW3-ztKEFj1MtJfDqEc0xoftMFeN=WA@mail.gmail.com> (raw)
In-Reply-To: <xmqq37f7gyuj.fsf_-_@gitster.mtv.corp.google.com>
On Tue, Feb 21, 2017 at 10:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The parsing of one-shot assignments of configuration variables that
> come from the command line historically was quite loose and allowed
> anything to pass.
>
> The configuration variable names that come from files are validated
> in git_config_parse_source(), which uses get_base_var() that grabs
> the <section> (and subsection) while making sure that <section>
> consists of iskeychar() letters, the function itself that makes sure
> that the first letter in <variable> is isalpha(), and get_value()
> that grabs the remainder of the <variable> name while making sure
> that it consists of iskeychar() letters.
>
> Perform an equivalent check in canonicalize_config_variable_name()
> to catch invalid configuration variable names that come from the
> command line.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > One thing I noticed is that "git config --get X" will correctly
> > diagnose that a dot-less X is not a valid variable name, but we do
> > not seem to diagnose "git -c X=V <cmd>" as invalid.
> >
> > Perhaps we should, but it is not the focus of this topic.
>
> And here is a follow-up on that tangent.
Combining this thought with another email[1] that flew by,
do we also need to have this treatment for "git clone -c"
[1] http://public-inbox.org/git/EC270E42-9431-446C-96F9-E1A0C3E45333@gmail.com/
>
> +for VAR in a .a a. a.0b a."b c". a."b c".0d
> +do
> + test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
> + test_must_fail git -c $VAR=VAL config -l
> + '
> +done
> +
> test_expect_success 'git -c is not confused by empty environment' '
> GIT_CONFIG_PARAMETERS="" git -c x.one=1 config --list
Do we also want to test obscure cases of expected success?
e.g. I suspect we never use a."b c".d in the test suite elsewhere but it
would be a valid key to be handed to git?
next prev parent reply other threads:[~2017-02-21 19:16 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 11:17 [BUG] submodule config does not apply to upper case submodules? Lars Schneider
2017-02-15 11:33 ` [PATCH v1] t7400: cleanup "submodule add clone shallow submodule" test Lars Schneider
2017-02-15 18:29 ` Stefan Beller
2017-02-15 18:39 ` Junio C Hamano
2017-02-15 18:14 ` [BUG] submodule config does not apply to upper case submodules? Stefan Beller
2017-02-15 18:53 ` Junio C Hamano
2017-02-15 22:54 ` Jonathan Tan
2017-02-15 23:02 ` Junio C Hamano
2017-02-15 23:11 ` Junio C Hamano
2017-02-15 23:28 ` Stefan Beller
2017-02-15 23:37 ` Junio C Hamano
2017-02-15 23:43 ` Stefan Beller
2017-02-15 23:53 ` Junio C Hamano
2017-02-16 23:22 ` Jeff King
2017-02-15 23:33 ` Jonathan Tan
2017-02-16 18:49 ` Junio C Hamano
2017-02-15 23:48 ` [PATCH] config: preserve <subsection> case for one-shot config on the command line Junio C Hamano
2017-02-16 10:30 ` Lars Schneider
2017-02-16 16:59 ` Junio C Hamano
2017-02-16 23:27 ` Jeff King
2017-02-17 1:25 ` Junio C Hamano
2017-02-20 9:58 ` Junio C Hamano
2017-02-20 17:17 ` Lars Schneider
2017-02-21 7:38 ` Jeff King
2017-02-21 17:01 ` Junio C Hamano
2017-02-21 17:17 ` [PATCH v2] " Junio C Hamano
2017-02-21 17:50 ` Jeff King
2017-02-21 17:57 ` Stefan Beller
2017-02-21 18:53 ` [PATCH] config: reject invalid VAR in 'git -c VAR=VAL command' Junio C Hamano
2017-02-21 19:15 ` Stefan Beller [this message]
2017-02-21 20:33 ` Junio C Hamano
2017-02-21 21:24 ` [PATCH v2] " Junio C Hamano
2017-02-22 1:06 ` Junio C Hamano
2017-02-23 5:58 ` Jeff King
2017-02-23 7:19 ` Junio C Hamano
2017-02-23 23:19 ` Junio C Hamano
2017-02-24 0:41 ` Jeff King
2017-02-24 4:17 ` Junio C Hamano
2017-02-24 4:22 ` Jeff King
2017-02-24 6:08 ` Junio C Hamano
2017-02-24 6:10 ` Jeff King
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
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 \
--in-reply-to='CAGZ79kbR2QQyYO1dnQ0jW3-ztKEFj1MtJfDqEc0xoftMFeN=WA@mail.gmail.com' \
--to=sbeller@google.com \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).