From 7d9a2819415663ee5f0676d06cdbb1368fdc02c7 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Mon, 24 Feb 2014 02:36:22 -0500 Subject: t4212: test bogus timestamps with git-log When t4212 was originally added by 9dbe7c3d (pretty: handle broken commit headers gracefully, 2013-04-17), it tested our handling of commits with broken ident lines in which the timestamps could not be parsed. It does so using a bogus line like "Name -<> 1234 -0000", because that simulates an error that was seen in the wild. Later, 03818a4 (split_ident: parse timestamp from end of line, 2013-10-14) made our parser smart enough to actually find the timestamp on such a line, and t4212 was adjusted to match. While it's nice that we handle this real-world case, this meant that we were not actually testing the bogus-timestamp case anymore. This patch adds a test with a totally incomprehensible timestamp to make sure we are testing the code path. Note that the behavior is slightly different between regular log output and "--format=%ad". In the former case, we produce a sentinel value and in the latter, we produce an empty string. While at first this seems unnecessarily inconsistent, it matches the original behavior given by 9dbe7c3d. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- t/t4212-log-corrupt.sh | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 't/t4212-log-corrupt.sh') diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh index ec5099b83d..611b687a3c 100755 --- a/t/t4212-log-corrupt.sh +++ b/t/t4212-log-corrupt.sh @@ -39,4 +39,25 @@ test_expect_success 'git log --format with broken author email' ' test_cmp expect.err actual.err ' +munge_author_date () { + git cat-file commit "$1" >commit.orig && + sed "s/^\(author .*>\) [0-9]*/\1 $2/" commit.munge && + git hash-object -w -t commit commit.munge +} + +test_expect_success 'unparsable dates produce sentinel value' ' + commit=$(munge_author_date HEAD totally_bogus) && + echo "Date: Thu Jan 1 00:00:00 1970 +0000" >expect && + git log -1 $commit >actual.full && + grep Date actual && + test_cmp expect actual +' + +test_expect_success 'unparsable dates produce sentinel value (%ad)' ' + commit=$(munge_author_date HEAD totally_bogus) && + echo >expect && + git log -1 --format=%ad $commit >actual + test_cmp expect actual +' + test_done -- cgit v1.2.3 From 1dca155fe3fac29e847d2d8ff1087d892a129a9c Mon Sep 17 00:00:00 2001 From: Jeff King Date: Mon, 24 Feb 2014 02:46:37 -0500 Subject: log: handle integer overflow in timestamps If an ident line has a ridiculous date value like (2^64)+1, we currently just pass ULONG_MAX along to the date code, which can produce nonsensical dates. On systems with a signed long time_t (e.g., 64-bit glibc systems), this actually doesn't end up too bad. The ULONG_MAX is converted to -1, we apply the timezone field to that, and the result ends up somewhere between Dec 31, 1969 and Jan 1, 1970. However, there is still a few good reasons to detect the overflow explicitly: 1. On systems where "unsigned long" is smaller than time_t, we get a nonsensical date in the future. 2. Even where it would produce "Dec 31, 1969", it's easier to recognize "midnight Jan 1" as a consistent sentinel value for "we could not parse this". 3. Values which do not overflow strtoul but do overflow a signed time_t produce nonsensical values in the past. For example, on a 64-bit system with a signed long time_t, a timestamp of 18446744073000000000 produces a date in 1947. We also recognize overflow in the timezone field, which could produce nonsensical results. In this case we show the parsed date, but in UTC. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- t/t4212-log-corrupt.sh | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 't/t4212-log-corrupt.sh') diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh index 611b687a3c..80542d624b 100755 --- a/t/t4212-log-corrupt.sh +++ b/t/t4212-log-corrupt.sh @@ -60,4 +60,20 @@ test_expect_success 'unparsable dates produce sentinel value (%ad)' ' test_cmp expect actual ' +# date is 2^64 + 1 +test_expect_success 'date parser recognizes integer overflow' ' + commit=$(munge_author_date HEAD 18446744073709551617) && + echo "Thu Jan 1 00:00:00 1970 +0000" >expect && + git log -1 --format=%ad $commit >actual && + test_cmp expect actual +' + +# date is 2^64 - 2 +test_expect_success 'date parser recognizes time_t overflow' ' + commit=$(munge_author_date HEAD 18446744073709551614) && + echo "Thu Jan 1 00:00:00 1970 +0000" >expect && + git log -1 --format=%ad $commit >actual && + test_cmp expect actual +' + test_done -- cgit v1.2.3 From 2b15846dbfb31df10a69a4d56ae944a01563bc07 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Mon, 24 Feb 2014 02:49:05 -0500 Subject: log: do not segfault on gmtime errors Many code paths assume that show_date and show_ident_date cannot return NULL. For the most part, we handle missing or corrupt timestamps by showing the epoch time t=0. However, we might still return NULL if gmtime rejects the time_t we feed it, resulting in a segfault. Let's catch this case and just format t=0. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- t/t4212-log-corrupt.sh | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 't/t4212-log-corrupt.sh') diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh index 80542d624b..85c6df4ec9 100755 --- a/t/t4212-log-corrupt.sh +++ b/t/t4212-log-corrupt.sh @@ -76,4 +76,12 @@ test_expect_success 'date parser recognizes time_t overflow' ' test_cmp expect actual ' +# date is within 2^63-1, but enough to choke glibc's gmtime +test_expect_success 'absurdly far-in-future dates produce sentinel' ' + commit=$(munge_author_date HEAD 999999999999999999) && + echo "Thu Jan 1 00:00:00 1970 +0000" >expect && + git log -1 --format=%ad $commit >actual && + test_cmp expect actual +' + test_done -- cgit v1.2.3