This particular SHA-1 has special meaning to git, very much like NULL
in C. If a user adds a file that has this SHA-1, unexpected things can
happen.
Granted, the chance is probably near zero because the content must
also start with valid blob header. But extra safety does not harm.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
---
Another way than die() is to detect this situation and update header a
little to give different SHA-1 (for example a leading 0 in object
size in header). Older git versions may not be happy with such an
approach.
The same check can be added to commit, tree, tag creation and fsck.
Maybe I'm too paranoid.
By the way, are any other SHA-1s sensitive to git like this one?
sha1_file.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 064a330..76be0dd 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2748,6 +2748,11 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st,
else
ret = index_stream(sha1, fd, size, type, path, flags);
close(fd);
+ if (!ret && is_null_sha1(sha1))
+ die(_("You are very unluckly.\n"
+ "You cannot add '%s' because this particular SHA-1 is used internally by git.\n"
+ "Any chance you can modify this file just a little to give different SHA-1?"),
+ path);
return ret;
}
--
1.7.3.1.256.g2539c.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html