Sorta OT, but I'm curious,
On Sun, Apr 21, 2013 at 12:09 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> For example, whenever git adds (or plans) support for a new header
> line in commit objects, before you've upgraded, a prankster can
> provide a bad value for that header line in objects they hand-craft.
> "git fsck" in your older version of git will accept the resulting
> objects on the assumption that they came from a newer version of git,
> so you won't notice. Later you upgrade Git and "git fsck" considers
> the objects malformed. Clients with "[transfer] fsckobjects" enabled
> start to reject your history. That is, this person has made your
> repository corrupt in the eyes of "git fsck".
> The usual excellent integrity checking will let you pinpoint the
> problem to the merge from that untrusted person so you can avoid
> trusting them again, and all the data will be there to recover without
> them. So it is auditable later. But this does mean that with the
> current design, there is some level of trust required to let someone
> commit into your history unless you inspect their work with a
> fine-toothed comb.
Has anyone written a test case for this?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html