Re: git log -p unexpected behaviour - security risk?

[shawn wilson <ag4ve.us@gmail.com>]

Sorta OT, but I'm curious,

On Sun, Apr 21, 2013 at 12:09 PM, Jonathan Nieder <jrnieder@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?