Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 23, 2011 at 6:21 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
> On 09/23/2011 12:39 AM, Junio C Hamano wrote:
>> [...] It
>> would be a regression if the attributes mechanism is used for auditing
>> purposes (as we start reading from a tree that is being audited using the
>> very attributes it brings in), though.
>
> I'm confused by this comment.
>
> If an auditing system can be subverted by altering .gitattributes, then
> I can do just as much harm by changing the .gitattributes in one commit
> and making the "nasty" change in a second.  So any rigorous auditing
> system based on .gitattributes would have to prevent me from committing
> modifications to .gitattributes, in which case my commit will be
> rejected anyway.
>
> If by "auditing" you mean other less rigorous checks to which exceptions
> are *allowed*, then it is preferable to add the exception in the same
> commit as the otherwise-offending content, and therefore it is
> *required* that the .gitattributes of the new tree be used when checking
> the contents of that tree.

Currently, an auditing hook that cares about attributes, and which
runs in a bare repo, ignores the in-repo .gitattributes, considering
only the attributes set outside of the repo.

So by making git care about .gitattributes in a bare repo, such a hook
can suddenly be bypassed.

j.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]