fast-export: use xmemdupz() for anonymizing oids

Our anonymize_mem() function is careful to take a ptr/len pair to allow
storing binary tokens like object ids, as well as partial strings (e.g.,
just "foo" of "foo/bar"). But it duplicates the hash key using
xstrdup()! That means that:

  - for a partial string, we'd store all bytes up to the NUL, even
    though we'd never look at anything past "len". This didn't produce
    wrong behavior, but was wasteful.

  - for a binary oid that doesn't contain a zero byte, we'd copy garbage
    bytes off the end of the array (though as long as nothing complained
    about reading uninitialized bytes, further reads would be limited by
    "len", and we'd produce the correct results)

  - for a binary oid that does contain a zero byte, we'd copy _fewer_
    bytes than intended into the hashmap struct. When we later try to
    look up a value, we'd access uninitialized memory and potentially
    falsely claim that a particular oid is not present.

The most common reason to store an oid is an anonymized gitlink, but our
test case doesn't have any gitlinks at all. So let's add one whose oid
contains a NUL and is present at two different paths. ASan catches the
memory error, but even without it we can detect the bug because the oid
is not anonymized the same way for both paths.

And of course the fix is to copy the correct number of bytes. We don't
technically need the appended NUL from xmemdupz(), but it doesn't hurt
as an extra protection against anybody treating it like a string (plus a
future patch will push us more in that direction).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 85868162eec9b0080ab30e7b1b8de1560c5ce5f2..289395a131392b0bf23cd5b3c457b13b1f4237ab 100644 (file)
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -162,7 +162,7 @@ static const void *anonymize_mem(struct hashmap *map,
        if (!ret) {
                ret = xmalloc(sizeof(*ret));
                hashmap_entry_init(&ret->hash, key.hash.hash);
-               ret->orig = xstrdup(orig);
+               ret->orig = xmemdupz(orig, *len);
                ret->orig_len = *len;
                ret->anon = generate(orig, len);
                ret->anon_len = *len;

diff --git a/t/t9351-fast-export-anonymize.sh b/t/t9351-fast-export-anonymize.sh
index e772cf993082e9f18cbe8b69d39bafa4b3fa54fe..dc5d75cd19705f528c8a59ac631298b431ea8eec 100755 (executable)
--- a/t/t9351-fast-export-anonymize.sh
+++ b/t/t9351-fast-export-anonymize.sh
@@ -10,6 +10,10 @@ test_expect_success 'setup simple repo' '
        mkdir subdir &&
        test_commit subdir/bar &&
        test_commit subdir/xyzzy &&
+       fake_commit=$(echo $ZERO_OID | sed s/0/a/) &&
+       git update-index --add --cacheinfo 160000,$fake_commit,link1 &&
+       git update-index --add --cacheinfo 160000,$fake_commit,link2 &&
+       git commit -m "add gitlink" &&
        git tag -m "annotated tag" mytag
 '
 
@@ -26,6 +30,12 @@ test_expect_success 'stream omits path names' '
        ! grep xyzzy stream
 '
 
+test_expect_success 'stream omits gitlink oids' '
+       # avoid relying on the whole oid to remain hash-agnostic; this is
+       # plenty to be unique within our test case
+       ! grep a000000000000000000 stream
+'
+
 test_expect_success 'stream allows master as refname' '
        grep master stream
 '
@@ -89,6 +99,11 @@ test_expect_success 'paths in subdir ended up in one tree' '
        test_cmp expect actual
 '
 
+test_expect_success 'identical gitlinks got identical oid' '
+       awk "/commit/ { print \$3 }" <root | sort -u >commits &&
+       test_line_count = 1 commits
+'
+
 test_expect_success 'tag points to branch tip' '
        git rev-parse $other_branch >expect &&
        git for-each-ref --format="%(*objectname)" | grep . >actual &&