3 ms·
Do you know if git objects' size header was designed to deal with a possible collision or does it serve another purpose as well? Just some context - git calcul
by almog 10y ago
Do you know if git objects' size header was designed to deal with a possible collision or does it serve another purpose as well?
Just some context - git calculates an object's name by his content in the following way. Say we have a blob that represent a file who's content is 'Here be dragons', then the file name would be:
printf "blob 17\0Here be dragons\!\n" | openssl sha1
# => a54eff8e0fa05c40cca0ab3851be5aa8058f20ea
So the object gets stored in '.git/objects/a5/4eff8e0fa05c40cca0ab3851be5aa8058f20ea'
- petertodd 10y agoActually AFAIK this specific attack doesn't let the two files have different lengths, so the size header is irrelevant anyway.
- the_common_man 10y agoThe size is useful when you want to know the length of an object without unpacking it. The size is uncompressed length and not the size on disk. For example, if you want to stream the blob over http you can use it to set the content-length. Otherwise, you have to use chunked transfer.
- hannibalhorn 10y agoThe PDF's released as proof are the same size, so if size and checksum are the same, git could certainly be fooled at checkout time. So I could imagine in a large source file, it would be possible to have some malicious code plus some data in comment blocks to make the hash match. That said, the PDF's are 422k, and I think it's a much more difficult attack on more typical, smaller size source files that one would typically check out and build from git. Maybe Xcode .nibs and that sort of tool output could become relatively easy attack vectors, though.
- Kubuxu 10y agoAlso git compresses before hashing IIRC.
- andrewshadura 10y agoIt doesn't.