[PATCH] Prevent git-config from storing section keys that are too long

[PATCH] Prevent git-config from storing section keys that are too long

[Ben Walton]

Key names have a length limit defined by MAXNAME in config.c.  When
reading the config file, we reserve half of this limit for the section
identifier and the other half for the key name within that section.

For example, if setting a key named url.foo.insteadOf, url.foo may use
at most half of MANXNAME.

The parser will throw an error if this condition is violated.

This patch ensures that git-config enforces the same restriction
during the creation of a section identifier so that it doesn't allow
the generate a configuration file that cannot be re-read later.

This patch also adds a test to t1303-wacky-config to catch any future
issues with this check.

Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---

Hi All,

I happened to notice this while running the test suite in a deeply
nested directory...

The check for baselen exceeding half of MAXNAME could be done earlier
in the function but doing it late allowed the error message to be
clearer without extra hassle.

I also wonder if MAXNAME should be increased somewhat.  Section
identifiers generated from keys like:

url./some/really/long/path.insteadOf

could overrun the current limit.  It's not a common case, of course,
or this issue would have been found sooner.  Would doubling the
current limit be out of the question?

Thanks
-Ben



 config.c                |    8 ++++++++
 t/t1303-wacky-config.sh |    4 ++++
 2 files changed, 12 insertions(+)

diff --git a/config.c b/config.c
index 2b706ea..d3f4854 100644
--- a/config.c
+++ b/config.c
@@ -1276,6 +1276,14 @@ int git_config_parse_key(const char *key, char **store_key, int *baselen_)
 	}
 	(*store_key)[i] = 0;
 
+	if (baselen > MAXNAME / 2) {
+		/* ok to destroy this value now since it will be freed */
+		(*store_key)[baselen] = '\0';
+		error("section identifier for key is too long (> %d): %s",
+		      MAXNAME / 2, *store_key);
+		goto out_free_ret_1;
+	}
+
 	return 0;
 
 out_free_ret_1:
diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
index 46103a1..12f0850 100755
--- a/t/t1303-wacky-config.sh
+++ b/t/t1303-wacky-config.sh
@@ -47,4 +47,8 @@ test_expect_success 'do not crash on special long config line' '
 	check section.key "$LONG_VALUE"
 '
 
+test_expect_success 'do not accept long section identifiers for key names' '
+	test_must_fail git config some.REALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlongREALLYlong.key value
+'
+
 test_done
-- 
1.7.9.5

Re: [PATCH] Prevent git-config from storing section keys that are too long

[Junio C Hamano]

Ben Walton <bwalton@artsci.utoronto.ca> writes:

> Key names have a length limit defined by MAXNAME in config.c.  When
> reading the config file, we reserve half of this limit for the section
> identifier and the other half for the key name within that section.
>
> For example, if setting a key named url.foo.insteadOf, url.foo may use
> at most half of MANXNAME.
>
> The parser will throw an error if this condition is violated.
>
> This patch ensures that git-config enforces the same restriction
> during the creation of a section identifier so that it doesn't allow
> the generate a configuration file that cannot be re-read later.
>
> This patch also adds a test to t1303-wacky-config to catch any future
> issues with this check.
>
> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
> ---
>
> Hi All,
>
> I happened to notice this while running the test suite in a deeply
> nested directory...
>
> The check for baselen exceeding half of MAXNAME could be done earlier
> in the function but doing it late allowed the error message to be
> clearer without extra hassle.
>
> I also wonder if MAXNAME should be increased somewhat.  Section
> identifiers generated from keys like:
>
> url./some/really/long/path.insteadOf
>
> could overrun the current limit.  It's not a common case, of course,
> or this issue would have been found sooner.  Would doubling the
> current limit be out of the question?

Is there a reason to have _any_ limitation?  It is not like we store
configuration data by allocating one file per item (in which case we
may be limited by the filesystem limit for direntry size), so if it
is not too much trouble, I think the right thing to do is to lift
the limitation altogether, possibly using strbuf instead of a
statically sized array of characters.

Of course, once you write a very long entry using a newer version of
Git, the resulting configuration file may end up unusable by older
version of Git, so a patch to implement such a change may need to be
based on older maintenance release (say maint-1.7.9) and then merged
upwards, but otherwise I do not offhand see a compatibility downside
of such a change.

Re: [PATCH] Prevent git-config from storing section keys that are too long

[Ben Walton]

Excerpts from Junio C Hamano's message of Thu Sep 06 21:33:20 -0400 2012:

Hi Junio,

> > identifiers generated from keys like:
> >
> > url./some/really/long/path.insteadOf
> >
> > could overrun the current limit.  It's not a common case, of course,
> > or this issue would have been found sooner.  Would doubling the
> > current limit be out of the question?
> 
> Is there a reason to have _any_ limitation?  It is not like we store
> configuration data by allocating one file per item (in which case we
> may be limited by the filesystem limit for direntry size), so if it
> is not too much trouble, I think the right thing to do is to lift
> the limitation altogether, possibly using strbuf instead of a
> statically sized array of characters.

I thought it made sense to impose some sort of bound here but removing
the limit wouldn't encourage the use of ridiculously long names so
lifting it entirely shouldn't hurt.

Any chosen limit would always be somewhat arbitrary.  I had considered
extending it to (PATHMAX + x) where x would also be arbitrary as
that would allow any valid url./path/max.insteadOf type setting but
that didn't seem like a good approach.

Removing the limit is a much better choice...

> Of course, once you write a very long entry using a newer version of
> Git, the resulting configuration file may end up unusable by older
> version of Git, so a patch to implement such a change may need to be
> based on older maintenance release (say maint-1.7.9) and then merged
> upwards, but otherwise I do not offhand see a compatibility downside
> of such a change.

I'm ok with this approach and will put an altered patch together
shortly.  I think it's fairly unlikely, but not impossible, that
anyone creating a config file with long key names would be in a
situation where someone else couldn't read that same config file.
I'll still base the change on maint-1.7.9 as suggested though.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

[PATCH] Remove the hard coded length limit on variable names in config files

[Ben Walton]

Previously while reading the variable names in config files, there was
a 256 character limit with at most 128 of those characters being used
by the section header portion of the variable name.  This limitation
was only enforced while reading the config files.  It was possible to
write a config file that was not subsequently readable.

Instead of enforcing this limitation for both reading and writing,
remove it entirely by changing the var member of the config_file
struct to a strbuf instead of a fixed length buffer.  Update all of
the parsing functions in config.c to use the strbuf instead of the
static buffer.  Send the buf member of the strbuf to external callback
functions to preserve the external api.

Signed-off-by: Ben Walton <bdwalton@gmail.com>
---
Hi Junio,

(Sorry that this patch took so long to submit.  I've been busy moving.)

I think this should remove the length limitations enforced while reading
configuration file variable names.

Thanks
-Ben

 config.c |   50 +++++++++++++++++++++++---------------------------
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/config.c b/config.c
index 40f9c6d..ee860a7 100644
--- a/config.c
+++ b/config.c
@@ -10,8 +10,6 @@
 #include "strbuf.h"
 #include "quote.h"
 
-#define MAXNAME (256)
-
 typedef struct config_file {
 	struct config_file *prev;
 	FILE *f;
@@ -19,7 +17,7 @@ typedef struct config_file {
 	int linenr;
 	int eof;
 	struct strbuf value;
-	char var[MAXNAME];
+	struct strbuf var;
 } config_file;
 
 static config_file *cf;
@@ -191,7 +189,7 @@ static inline int iskeychar(int c)
 	return isalnum(c) || c == '-';
 }
 
-static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
+static int get_value(config_fn_t fn, void *data, struct strbuf *name)
 {
 	int c;
 	char *value;
@@ -203,11 +201,9 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
 			break;
 		if (!iskeychar(c))
 			break;
-		name[len++] = tolower(c);
-		if (len >= MAXNAME)
-			return -1;
+		strbuf_addch(name, tolower(c));
 	}
-	name[len] = 0;
+
 	while (c == ' ' || c == '\t')
 		c = get_next_char();
 
@@ -219,10 +215,10 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
 		if (!value)
 			return -1;
 	}
-	return fn(name, value, data);
+	return fn(name->buf, value, data);
 }
 
-static int get_extended_base_var(char *name, int baselen, int c)
+static int get_extended_base_var(struct strbuf *name, int c)
 {
 	do {
 		if (c == '\n')
@@ -233,7 +229,7 @@ static int get_extended_base_var(char *name, int baselen, int c)
 	/* We require the format to be '[base "extension"]' */
 	if (c != '"')
 		return -1;
-	name[baselen++] = '.';
+	strbuf_addch(name, '.');
 
 	for (;;) {
 		int c = get_next_char();
@@ -246,34 +242,30 @@ static int get_extended_base_var(char *name, int baselen, int c)
 			if (c == '\n')
 				return -1;
 		}
-		name[baselen++] = c;
-		if (baselen > MAXNAME / 2)
-			return -1;
+		strbuf_addch(name, c);
 	}
 
 	/* Final ']' */
 	if (get_next_char() != ']')
 		return -1;
-	return baselen;
+	return name->len;
 }
 
-static int get_base_var(char *name)
+static int get_base_var(struct strbuf *name)
 {
-	int baselen = 0;
+	strbuf_reset(name);
 
 	for (;;) {
 		int c = get_next_char();
 		if (cf->eof)
 			return -1;
 		if (c == ']')
-			return baselen;
+			return name->len;
 		if (isspace(c))
-			return get_extended_base_var(name, baselen, c);
+			return get_extended_base_var(name, c);
 		if (!iskeychar(c) && c != '.')
 			return -1;
-		if (baselen > MAXNAME / 2)
-			return -1;
-		name[baselen++] = tolower(c);
+		strbuf_addch(name, tolower(c));
 	}
 }
 
@@ -281,7 +273,7 @@ static int git_parse_file(config_fn_t fn, void *data)
 {
 	int comment = 0;
 	int baselen = 0;
-	char *var = cf->var;
+	struct strbuf *var = &cf->var;
 
 	/* U+FEFF Byte Order Mark in UTF8 */
 	static const unsigned char *utf8_bom = (unsigned char *) "\xef\xbb\xbf";
@@ -320,14 +312,16 @@ static int git_parse_file(config_fn_t fn, void *data)
 			baselen = get_base_var(var);
 			if (baselen <= 0)
 				break;
-			var[baselen++] = '.';
-			var[baselen] = 0;
+			strbuf_addch(var, '.');
 			continue;
 		}
 		if (!isalpha(c))
 			break;
-		var[baselen] = tolower(c);
-		if (get_value(fn, data, var, baselen+1) < 0)
+		/* Truncate the var name back to the section header prior to
+		   grabbing the suffix part of the name and the value */
+		strbuf_setlen(var, baselen+1);
+		strbuf_addch(var, tolower(c));
+		if (get_value(fn, data, var) < 0)
 			break;
 	}
 	die("bad config file line %d in %s", cf->linenr, cf->name);
@@ -842,12 +836,14 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 		top.linenr = 1;
 		top.eof = 0;
 		strbuf_init(&top.value, 1024);
+		strbuf_init(&top.var, 1024);
 		cf = &top;
 
 		ret = git_parse_file(fn, data);
 
 		/* pop config-file parsing state stack */
 		strbuf_release(&top.value);
+		strbuf_release(&top.var);
 		cf = top.prev;
 
 		fclose(f);
-- 
1.7.9.5

Re: [PATCH] Remove the hard coded length limit on variable names in config files

[Michael Haggerty]

On 09/29/2012 12:19 PM, Ben Walton wrote:
> Previously while reading the variable names in config files, there was
> a 256 character limit with at most 128 of those characters being used
> by the section header portion of the variable name.  This limitation
> was only enforced while reading the config files.  It was possible to
> write a config file that was not subsequently readable.
> 
> Instead of enforcing this limitation for both reading and writing,
> remove it entirely by changing the var member of the config_file
> struct to a strbuf instead of a fixed length buffer.  Update all of
> the parsing functions in config.c to use the strbuf instead of the
> static buffer.  Send the buf member of the strbuf to external callback
> functions to preserve the external api.
> 
> Signed-off-by: Ben Walton <bdwalton@gmail.com>
> ---
> Hi Junio,
> 
> (Sorry that this patch took so long to submit.  I've been busy moving.)

The patch doesn't apply to the current master; it appears to have been
built against master 883a2a3504 (2012-02-23) or older.  It will have to
be rebased to the current master.

Nevertheless I will add a few comments below.

Overall, I like your approach of using strbuf here, as it is simpler to
use and less error-prone.  It is also nice to get rid of an arbitrary
length limit, especially since it was not consistently enforced.

> I think this should remove the length limitations enforced while reading
> configuration file variable names.
> 
> Thanks
> -Ben
> 
>  config.c |   50 +++++++++++++++++++++++---------------------------
>  1 file changed, 23 insertions(+), 27 deletions(-)
> 
> diff --git a/config.c b/config.c
> index 40f9c6d..ee860a7 100644
> --- a/config.c
> +++ b/config.c
> @@ -10,8 +10,6 @@
>  #include "strbuf.h"
>  #include "quote.h"
>  
> -#define MAXNAME (256)
> -
>  typedef struct config_file {
>  	struct config_file *prev;
>  	FILE *f;
> @@ -19,7 +17,7 @@ typedef struct config_file {
>  	int linenr;
>  	int eof;
>  	struct strbuf value;
> -	char var[MAXNAME];
> +	struct strbuf var;
>  } config_file;
>  
>  static config_file *cf;
> @@ -191,7 +189,7 @@ static inline int iskeychar(int c)
>  	return isalnum(c) || c == '-';
>  }
>  
> -static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
> +static int get_value(config_fn_t fn, void *data, struct strbuf *name)
>  {
>  	int c;
>  	char *value;
> @@ -203,11 +201,9 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
>  			break;
>  		if (!iskeychar(c))
>  			break;
> -		name[len++] = tolower(c);
> -		if (len >= MAXNAME)
> -			return -1;
> +		strbuf_addch(name, tolower(c));
>  	}
> -	name[len] = 0;
> +
>  	while (c == ' ' || c == '\t')
>  		c = get_next_char();
>  
> @@ -219,10 +215,10 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
>  		if (!value)
>  			return -1;
>  	}
> -	return fn(name, value, data);
> +	return fn(name->buf, value, data);
>  }
>  
> -static int get_extended_base_var(char *name, int baselen, int c)
> +static int get_extended_base_var(struct strbuf *name, int c)
>  {
>  	do {
>  		if (c == '\n')
> @@ -233,7 +229,7 @@ static int get_extended_base_var(char *name, int baselen, int c)
>  	/* We require the format to be '[base "extension"]' */
>  	if (c != '"')
>  		return -1;
> -	name[baselen++] = '.';
> +	strbuf_addch(name, '.');
>  
>  	for (;;) {
>  		int c = get_next_char();
> @@ -246,34 +242,30 @@ static int get_extended_base_var(char *name, int baselen, int c)
>  			if (c == '\n')
>  				return -1;
>  		}
> -		name[baselen++] = c;
> -		if (baselen > MAXNAME / 2)
> -			return -1;
> +		strbuf_addch(name, c);
>  	}
>  
>  	/* Final ']' */
>  	if (get_next_char() != ']')
>  		return -1;
> -	return baselen;
> +	return name->len;
>  }
>  
> -static int get_base_var(char *name)
> +static int get_base_var(struct strbuf *name)
>  {
> -	int baselen = 0;
> +	strbuf_reset(name);
>  
>  	for (;;) {
>  		int c = get_next_char();
>  		if (cf->eof)
>  			return -1;
>  		if (c == ']')
> -			return baselen;
> +			return name->len;
>  		if (isspace(c))
> -			return get_extended_base_var(name, baselen, c);
> +			return get_extended_base_var(name, c);
>  		if (!iskeychar(c) && c != '.')
>  			return -1;
> -		if (baselen > MAXNAME / 2)
> -			return -1;
> -		name[baselen++] = tolower(c);
> +		strbuf_addch(name, tolower(c));
>  	}
>  }
>  
> @@ -281,7 +273,7 @@ static int git_parse_file(config_fn_t fn, void *data)
>  {
>  	int comment = 0;
>  	int baselen = 0;
> -	char *var = cf->var;
> +	struct strbuf *var = &cf->var;
>  
>  	/* U+FEFF Byte Order Mark in UTF8 */
>  	static const unsigned char *utf8_bom = (unsigned char *) "\xef\xbb\xbf";
> @@ -320,14 +312,16 @@ static int git_parse_file(config_fn_t fn, void *data)
>  			baselen = get_base_var(var);
>  			if (baselen <= 0)
>  				break;
> -			var[baselen++] = '.';
> -			var[baselen] = 0;
> +			strbuf_addch(var, '.');
>  			continue;
>  		}
>  		if (!isalpha(c))
>  			break;
> -		var[baselen] = tolower(c);
> -		if (get_value(fn, data, var, baselen+1) < 0)
> +		/* Truncate the var name back to the section header prior to
> +		   grabbing the suffix part of the name and the value */
> +		strbuf_setlen(var, baselen+1);
> +		strbuf_addch(var, tolower(c));
> +		if (get_value(fn, data, var) < 0)
>  			break;
>  	}
>  	die("bad config file line %d in %s", cf->linenr, cf->name);

The preferred format for multiline comments in the git project is

    /*
     * Truncate the var name back to the section header prior to
     * grabbing the suffix part of the name and the value.
     */

It took me a while to figure out what you were doing here.  Let me
explain why.

In the old code, get_base_var() read the string into var and returned
var's length (or -1 on error).  The fact that the length of var was
first "reset" to zero is somewhat implicit in the fact that no length
parameter is being passed to get_base_var().

But in the new version, get_base_var() is passed a strbuf.  Often,
operations with strbufs append to the strbuf, and this is what I first
assumed.  It took me a while to realize that get_base_var() calls
strbuf_reset() before getting to work.  Moreover, get_base_var() still
returns the length of what it found, which is redundant with a strbuf
and therefore unexpected.  So when the return value of get_base_var() is
stored into baselen, it is not really obvious that it is the string's
length.

Therefore, I suggest

* Call strbuf_reset() directly in get_parse_file() rather than in
get_base_var()

* Change get_base_var() to return 0 on success (rather than the length
of the string) and -1 on error (including length==0, which is also an
error in this context).

* Change how get_parse_file() initializes baselen to

        if (get_base_var(var) < 0)
                break;
        strbuf_addch(var, '.');
        baselen = var->len;

Note that baselen now includes the trailing dot.  Then later, you don't
need the "+1":

        /*
         * Truncate the var name back to (section header plus '.')
         * prior to grabbing the suffix part of the name and the value
         */
        strbuf_setlen(var, baselen);
        strbuf_addch(var, tolower(c));
        if (get_value(fn, data, var) < 0)
        [...]

> @@ -842,12 +836,14 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
>  		top.linenr = 1;
>  		top.eof = 0;
>  		strbuf_init(&top.value, 1024);
> +		strbuf_init(&top.var, 1024);
>  		cf = &top;
>  
>  		ret = git_parse_file(fn, data);
>  
>  		/* pop config-file parsing state stack */
>  		strbuf_release(&top.value);
> +		strbuf_release(&top.var);
>  		cf = top.prev;
>  
>  		fclose(f);
> 

Finally, I realize that the MAXNAME constant was not exported and I
can't find the old length limits documented anywhere, but I nevertheless
worry a little bit that one of the users of the config API has a
built-in assumption that names can never be longer than 256 characters
(for example, a config_fn_t function might try to store the name into a
fixed-length buffer).  Hopefully such code would never have been written
or accepted, but...?  If you have thought about this or audited the
callers, please mention that in your commit message.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: [PATCH] Remove the hard coded length limit on variable names in config files

[Ben Walton]

Hi Michael,

> The patch doesn't apply to the current master; it appears to have been
> built against master 883a2a3504 (2012-02-23) or older.  It will have to
> be rebased to the current master.

Junio had asked that it be based on maint so that's what I (thought
I?) did.  I'm happy to redo it against master if that's better though.

> The preferred format for multiline comments in the git project is
>
>     /*
>      * Truncate the var name back to the section header prior to
>      * grabbing the suffix part of the name and the value.
>      */

Oops; Will fix.

> In the old code, get_base_var() read the string into var and returned
> var's length (or -1 on error).  The fact that the length of var was
> first "reset" to zero is somewhat implicit in the fact that no length
> parameter is being passed to get_base_var().
>
> But in the new version, get_base_var() is passed a strbuf.  Often,
> operations with strbufs append to the strbuf, and this is what I first
> assumed.  It took me a while to realize that get_base_var() calls
> strbuf_reset() before getting to work.  Moreover, get_base_var() still
> returns the length of what it found, which is redundant with a strbuf
> and therefore unexpected.  So when the return value of get_base_var() is
> stored into baselen, it is not really obvious that it is the string's
> length.

Ok, that's a fair criticism.  When I was creating the patch, I thought
that placing
the strbuf_reset in get_base_var() seemed nicer as it matched the
baselen = 0 which
effectively reset the old character array.  Your point is well taken
though and I think
it makes sense to switch things around the way you've suggested.

> Finally, I realize that the MAXNAME constant was not exported and I
> can't find the old length limits documented anywhere, but I nevertheless
> worry a little bit that one of the users of the config API has a
> built-in assumption that names can never be longer than 256 characters
> (for example, a config_fn_t function might try to store the name into a
> fixed-length buffer).  Hopefully such code would never have been written
> or accepted, but...?  If you have thought about this or audited the
> callers, please mention that in your commit message.

I did look through the code to see if anything was relying on fixed
size buffers and I didn't see anything.  I'll update the commit
message with this info too.

I'll send a modified patch shortly.

Thanks for the review!
-Ben
-- 
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself.  Much more happiness,
truth, beauty and wisdom will come to you that way.

-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------

[PATCH] Remove the hard coded length limit on variable names in config files

[Ben Walton]

Previously while reading the variable names in config files, there was
a 256 character limit with at most 128 of those characters being used
by the section header portion of the variable name.  This limitation
was only enforced while reading the config files.  It was possible to
write a config file that was not subsequently readable.

Instead of enforcing this limitation for both reading and writing,
remove it entirely by changing the var member of the config_file
struct to a strbuf instead of a fixed length buffer.  Update all of
the parsing functions in config.c to use the strbuf instead of the
static buffer.

The parsing functions that returned the base length of the variable
name now return simply 0 for success and -1 for failure.  The base
length information is obtained through the strbuf's len member.

We now send the buf member of the strbuf to external callback
functions to preserve the external api.  None of the external callers
rely on the old size limitation for sizing their own buffers so
removing the limit should have no externally visible effect.

Signed-off-by: Ben Walton <bdwalton@gmail.com>
---
 config.c |   59 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/config.c b/config.c
index 08e47e2..24fb2d2 100644
--- a/config.c
+++ b/config.c
@@ -10,8 +10,6 @@
 #include "strbuf.h"
 #include "quote.h"
 
-#define MAXNAME (256)
-
 typedef struct config_file {
 	struct config_file *prev;
 	FILE *f;
@@ -19,7 +17,7 @@ typedef struct config_file {
 	int linenr;
 	int eof;
 	struct strbuf value;
-	char var[MAXNAME];
+	struct strbuf var;
 } config_file;
 
 static config_file *cf;
@@ -260,7 +258,7 @@ static inline int iskeychar(int c)
 	return isalnum(c) || c == '-';
 }
 
-static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
+static int get_value(config_fn_t fn, void *data, struct strbuf *name)
 {
 	int c;
 	char *value;
@@ -272,11 +270,9 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
 			break;
 		if (!iskeychar(c))
 			break;
-		name[len++] = tolower(c);
-		if (len >= MAXNAME)
-			return -1;
+		strbuf_addch(name, tolower(c));
 	}
-	name[len] = 0;
+
 	while (c == ' ' || c == '\t')
 		c = get_next_char();
 
@@ -288,10 +284,10 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
 		if (!value)
 			return -1;
 	}
-	return fn(name, value, data);
+	return fn(name->buf, value, data);
 }
 
-static int get_extended_base_var(char *name, int baselen, int c)
+static int get_extended_base_var(struct strbuf *name, int c)
 {
 	do {
 		if (c == '\n')
@@ -302,7 +298,7 @@ static int get_extended_base_var(char *name, int baselen, int c)
 	/* We require the format to be '[base "extension"]' */
 	if (c != '"')
 		return -1;
-	name[baselen++] = '.';
+	strbuf_addch(name, '.');
 
 	for (;;) {
 		int c = get_next_char();
@@ -315,37 +311,31 @@ static int get_extended_base_var(char *name, int baselen, int c)
 			if (c == '\n')
 				goto error_incomplete_line;
 		}
-		name[baselen++] = c;
-		if (baselen > MAXNAME / 2)
-			return -1;
+		strbuf_addch(name, c);
 	}
 
 	/* Final ']' */
 	if (get_next_char() != ']')
 		return -1;
-	return baselen;
+	return 0;
 error_incomplete_line:
 	cf->linenr--;
 	return -1;
 }
 
-static int get_base_var(char *name)
+static int get_base_var(struct strbuf *name)
 {
-	int baselen = 0;
-
 	for (;;) {
 		int c = get_next_char();
 		if (cf->eof)
 			return -1;
 		if (c == ']')
-			return baselen;
+			return 0;
 		if (isspace(c))
-			return get_extended_base_var(name, baselen, c);
+			return get_extended_base_var(name, c);
 		if (!iskeychar(c) && c != '.')
 			return -1;
-		if (baselen > MAXNAME / 2)
-			return -1;
-		name[baselen++] = tolower(c);
+		strbuf_addch(name, tolower(c));
 	}
 }
 
@@ -353,7 +343,7 @@ static int git_parse_file(config_fn_t fn, void *data)
 {
 	int comment = 0;
 	int baselen = 0;
-	char *var = cf->var;
+	struct strbuf *var = &cf->var;
 
 	/* U+FEFF Byte Order Mark in UTF8 */
 	static const unsigned char *utf8_bom = (unsigned char *) "\xef\xbb\xbf";
@@ -389,17 +379,24 @@ static int git_parse_file(config_fn_t fn, void *data)
 			continue;
 		}
 		if (c == '[') {
-			baselen = get_base_var(var);
-			if (baselen <= 0)
+			/* Reset prior to determining a new stem */
+			strbuf_reset(var);
+			if (get_base_var(var) < 0 || var->len < 1)
 				break;
-			var[baselen++] = '.';
-			var[baselen] = 0;
+			strbuf_addch(var, '.');
+			baselen = var -> len;
 			continue;
 		}
 		if (!isalpha(c))
 			break;
-		var[baselen] = tolower(c);
-		if (get_value(fn, data, var, baselen+1) < 0)
+		/*
+		 * Truncate the var name back to the section header
+		 * stem prior to grabbing the suffix part of the name
+		 * and the value.
+		 */
+		strbuf_setlen(var, baselen);
+		strbuf_addch(var, tolower(c));
+		if (get_value(fn, data, var) < 0)
 			break;
 	}
 	die("bad config file line %d in %s", cf->linenr, cf->name);
@@ -899,12 +896,14 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 		top.linenr = 1;
 		top.eof = 0;
 		strbuf_init(&top.value, 1024);
+		strbuf_init(&top.var, 1024);
 		cf = &top;
 
 		ret = git_parse_file(fn, data);
 
 		/* pop config-file parsing state stack */
 		strbuf_release(&top.value);
+		strbuf_release(&top.var);
 		cf = top.prev;
 
 		fclose(f);
-- 
1.7.9.5

Re: [PATCH] Remove the hard coded length limit on variable names in config files

[Michael Haggerty]

On 09/30/2012 08:20 PM, Ben Walton wrote:
>> The patch doesn't apply to the current master; it appears to have been
>> built against master 883a2a3504 (2012-02-23) or older.  It will have to
>> be rebased to the current master.
> 
> Junio had asked that it be based on maint so that's what I (thought
> I?) did.  I'm happy to redo it against master if that's better though.

That explains it.  Sorry, I hadn't seen that conversation.  (In the
future, if a patch applies against something other than master, please
add a note in the cover letter or in the patch comment after the "--".)

It is OK with me to leave the patch against maint, if that is what Junio
wanted.  It would help, though, if you rebase it to the latest maint
(the conflict seems easy to fix).

Thanks,
Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: [PATCH] Remove the hard coded length limit on variable names in config files

[Junio C Hamano]

Ben Walton <bdwalton@gmail.com> writes:

> Previously while reading the variable names in config files, there was
> a 256 character limit with at most 128 of those characters being used
> by the section header portion of the variable name.  This limitation
> was only enforced while reading the config files.  It was possible to
> write a config file that was not subsequently readable.
>
> Instead of enforcing this limitation for both reading and writing,
> remove it entirely by changing the var member of the config_file
> struct to a strbuf instead of a fixed length buffer.  Update all of
> the parsing functions in config.c to use the strbuf instead of the
> static buffer.
>
> The parsing functions that returned the base length of the variable
> name now return simply 0 for success and -1 for failure.  The base
> length information is obtained through the strbuf's len member.
>
> We now send the buf member of the strbuf to external callback
> functions to preserve the external api.  None of the external callers
> rely on the old size limitation for sizing their own buffers so
> removing the limit should have no externally visible effect.
>
> Signed-off-by: Ben Walton <bdwalton@gmail.com>
> ---
>  config.c |   59 +++++++++++++++++++++++++++++------------------------------
>  1 file changed, 29 insertions(+), 30 deletions(-)

Makes sense, and I found the patch very readable.

Thanks, both.