Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes

From: Duy Nguyen <pclouds@gmail.com>
Date: Nov 8, 2016, 01:38 UTC
Message-ID: <CACsJy8BoEXDjwe=ZX5ZOC_mvaMjYrB3i7wcMmiOP3mm5-rwC5Q@mail.gmail.com>
In-Reply-To: <20161107211522.vzl4zpsu5cpembgc@sigill.intra.peff.net>

On Tue, Nov 8, 2016 at 4:15 AM, Jeff King <peff@peff.net> wrote:

Show 13 quoted lines

> On Mon, Nov 07, 2016 at 04:10:10PM -0500, Jeff King wrote:
>
>> And I'll admit my main motivation is not that index/filesystem parity,
>> but rather just that:
>>
>>   git clone git://host.com/malicious-repo.git
>>   git log
>>
>> might create and read symlinks to arbitrary files on the cloner's box.
>> I'm not sure to what degree to be worried about that. It's not like you
>> can't make other arbitrary symlinks which are likely to be read if the
>> user actually starts looking at checked-out files. It's just that we
>> usually try to make a clone+log of a malicious repository safe.

This I can buy.

> Another approach is to have a config option to disallow symlinks to
> destinations outside of the repository tree (I'm not sure if it should
> be on or off by default, though).

Let's err on the safe side and disable symlinks to outside repo by default (or even all symlinks on .gitattributes and .gitignore as the first step)

What I learned from my changes in .gitignore is, if we have not forbidden something, people likely find some creative use for it. As long as it's can be turned on or off, i guess those minority will stay happy.

Show 7 quoted lines

> Again, I don't know that there is a specific security issue, but it
> makes things easier for services which might clone untrusted
> repositories (e.g., things like CI). They'd obviously have to be careful
> with the contents of the repositories anyway, but it's one less thing to
> have to worry about.
>
> -Peff

-- 
Duy