git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH 1/2] config: properly range-check integer values
Date: Tue, 20 Aug 2013 18:42:57 -0400	[thread overview]
Message-ID: <20130820224256.GA24766@sigill.intra.peff.net> (raw)
In-Reply-To: <20130820223953.GA3429@sigill.intra.peff.net>

When we look at a config value as an integer using the
git_config_int function, we carefully range-check the value
we get and complain if it is out of our range. But the range
we compare to is that of a "long", which we then cast to an
"int" in the function's return value. This means that on
systems where "int" and "long" have different sizes (e.g.,
LP64 systems), we may pass the range check, but then return
nonsense by truncating the value as we cast it to an int.

We can solve this by converting git_parse_long into
git_parse_int, and range-checking the "int" range. Nobody
actually cared that we used a "long" internally, since the
result was truncated anyway, and there were no other callers
of git_parse_long.

Of the existing callers, all of them expect small-ish values
that are fine for an "int", and should not be impacted
except when nonsense is fed to them. The one arguable
exception is http.lowSpeedLimit, which is given in bytes per
second, and is fed to curl as a long. However, nobody is
likely to consider 2GB/sec as "low speed", and even if they
did, the new behavior is much better (it barfs and complains
rather than considering the value negative and silently
ignoring it).

Signed-off-by: Jeff King <peff@peff.net>
---
I added a test. It would not fail on existing 32-bit systems, but would
on existing LP64 systems. It will pass with the new code on both.
However, it will fail on ILP64 systems (because their int is large, and
can represent 3GB). I'm not sure if any such systems are in wide use
(SPARC64?), but we would want a prereq in that case, I guess. I'm
inclined to wait to see if it actually fails for anybody.

 config.c               | 12 ++++++------
 t/t1300-repo-config.sh |  5 +++++
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/config.c b/config.c
index e13a7b6..9237d4b 100644
--- a/config.c
+++ b/config.c
@@ -468,7 +468,7 @@ static int parse_unit_factor(const char *end, uintmax_t *val)
 	return 0;
 }
 
-static int git_parse_long(const char *value, long *ret)
+static int git_parse_int(const char *value, int *ret)
 {
 	if (value && *value) {
 		char *end;
@@ -484,7 +484,7 @@ static int git_parse_long(const char *value, long *ret)
 			return 0;
 		uval = abs(val);
 		uval *= factor;
-		if ((uval > maximum_signed_value_of_type(long)) ||
+		if ((uval > maximum_signed_value_of_type(int)) ||
 		    (abs(val) > uval))
 			return 0;
 		val *= factor;
@@ -526,8 +526,8 @@ int git_config_int(const char *name, const char *value)
 
 int git_config_int(const char *name, const char *value)
 {
-	long ret = 0;
-	if (!git_parse_long(value, &ret))
+	int ret;
+	if (!git_parse_int(value, &ret))
 		die_bad_config(name);
 	return ret;
 }
@@ -559,10 +559,10 @@ int git_config_maybe_bool(const char *name, const char *value)
 
 int git_config_maybe_bool(const char *name, const char *value)
 {
-	long v = git_config_maybe_bool_text(name, value);
+	int v = git_config_maybe_bool_text(name, value);
 	if (0 <= v)
 		return v;
-	if (git_parse_long(value, &v))
+	if (git_parse_int(value, &v))
 		return !!v;
 	return -1;
 }
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index c4a7d84..3c5ec4b 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -652,6 +652,11 @@ test_expect_success numbers '
 	test_cmp expect actual
 '
 
+test_expect_success 'out-of-range integers are detected' '
+	git config giga.crash 3g &&
+	test_must_fail git config --int giga.crash
+'
+
 test_expect_success 'invalid unit' '
 	git config aninvalid.unit "1auto" &&
 	echo 1auto >expect &&
-- 
1.8.4.rc2.28.g6bb5f3f

  reply	other threads:[~2013-08-20 22:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20 22:39 [PATCH 0/2] git-config and large integers Jeff King
2013-08-20 22:42 ` Jeff King [this message]
2013-08-20 23:07   ` [PATCH 1/2] config: properly range-check integer values Jonathan Nieder
2013-08-21  2:55     ` Jeff King
2013-08-20 22:44 ` [PATCH 0/2] git-config and large integers Stefan Beller
2013-08-20 22:48   ` Jeff King
2013-08-20 22:47 ` [PATCH 2/2] teach git-config to output " Jeff King
2013-08-20 22:57   ` Jonathan Nieder
2013-08-21  3:00     ` Jeff King
2013-08-21  4:38       ` Jonathan Nieder
2013-08-21  5:00         ` Jeff King
2013-08-21  6:34           ` Jonathan Nieder
2013-08-20 23:06 ` [PATCH 0/2] git-config and " Junio C Hamano
2013-08-20 23:41   ` Junio C Hamano
2013-08-21  2:43     ` Jeff King
2013-08-21  2:34   ` Jeff King
2013-09-08  8:27 ` [PATCHv2 0/5] " Jeff King
2013-09-08  8:29   ` [PATCH 1/5] config: factor out integer parsing from range checks Jeff King
2013-09-08  8:33   ` [PATCH 2/5] config: properly range-check integer values Jeff King
2013-09-08  8:36   ` [PATCH 3/5] config: set errno in numeric git_parse_* functions Jeff King
2013-09-09  0:36     ` Eric Sunshine
2013-09-09 19:53       ` Jeff King
2013-09-08  8:38   ` [PATCH 4/5] config: make numeric parsing errors more clear Jeff King
2013-09-08  8:40   ` [PATCH 5/5] git-config: always treat --int as 64-bit internally Jeff King
2013-09-09 18:58   ` [PATCHv2 0/5] git-config and large integers 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

  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=20130820224256.GA24766@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    /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).