@@ -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;
@@ -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 &&
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> --- builtin/fast-export.c | 2 +- t/t9351-fast-export-anonymize.sh | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-)