threads / patch / 31463

patchPrevent git-config from storing section keys that are too long

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

## tl;dr

9 messages between Sep 7, 2012 and Oct 1, 2012. Diffs are folded; open one to read it.

replies: 8people: 3as markdown or json

Ben Walton· Sep 7, 2012, 00:47 UTC · lore

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(+)
Show changes to 2 files +12 −0

config.c, t/t1303-wacky-config.sh

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
Junio C Hamano· Sep 7, 2012, 01:33 UTC · re: Ben Walton · lore

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

Ben Walton <bwalton@artsci.utoronto.ca> writes:
Show 36 quoted lines
> 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.

Ben Walton· Sep 7, 2012, 02:34 UTC · re: Junio C Hamano · lore

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

Excerpts from Junio C Hamano's message of Thu Sep 06 21:33:20 -0400 2012:
Hi Junio,
Show 14 quoted lines
> > 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...
Show 6 quoted lines
> 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

Ben Walton· Sep 29, 2012, 10:19 UTC · re: Junio C Hamano · lore

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

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(-)
Show changes to config.c +23 −27
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
Michael Haggerty· Sep 30, 2012, 04:05 UTC · re: Ben Walton · lore

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

On 09/29/2012 12:19 PM, Ben Walton wrote:
Show 18 quoted lines
> 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.

Show 148 quoted lines
> 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)
        [...]
Show 16 quoted lines
> @@ -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/
Ben Walton· Sep 30, 2012, 18:20 UTC · re: Michael Haggerty · lore

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

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.

Show 6 quoted lines
> 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.
Show 13 quoted lines
> 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.

Show 8 quoted lines
> 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
---------------------------------------------------------------------------------------------------------------------------
Ben Walton· Sep 30, 2012, 19:44 UTC · re: Ben Walton · lore

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

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(-)
Show changes to config.c +29 −30
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
Junio C Hamano· Oct 1, 2012, 19:33 UTC · re: Ben Walton · lore

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

Ben Walton <bdwalton@gmail.com> writes:
Show 25 quoted lines
> 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.
Michael Haggerty· Oct 1, 2012, 03:16 UTC · re: Ben Walton · lore

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

On 09/30/2012 08:20 PM, Ben Walton wrote:
Show 6 quoted lines
>> 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/

← back to recent threads