On Thu, Nov 10, 2016 at 7:23 AM, Jeff King wrote:
> On Wed, Nov 09, 2016 at 04:18:29PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
>> >
>> > I'm slightly confused. Did you mean "supporting any in-tree symlink to
>> >
Jeff King writes:
> On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
>
> I'm slightly confused. Did you mean "supporting any in-tree symlink to
> an out-of-tree destination" in your first sentence?
I was trying to say that these "control files used solely by git"
have no business
On Wed, Nov 09, 2016 at 04:18:29PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
> >
> > I'm slightly confused. Did you mean "supporting any in-tree symlink to
> > an out-of-tree destination" in your first sentence?
>
> I
On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > 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 .gitig
Duy Nguyen writes:
> 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
On Wed, Nov 09, 2016 at 12:41:22PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > For matching specific names, we have to deal with case-folding. It's
> > easy to hit the common ones like ".GITIGNORE" with fspathcmp(). But if
> > this is actually protection against malicious repositorie
Jeff King writes:
> For matching specific names, we have to deal with case-folding. It's
> easy to hit the common ones like ".GITIGNORE" with fspathcmp(). But if
> this is actually protection against malicious repositories, we have to
> match all of the horrible filesystem-specific junk that we
On Wed, Nov 09, 2016 at 04:22:12PM +0700, Duy Nguyen wrote:
> > Symlinks are likewise tricky. If we see that a symlink points to
> > "foo/../bar", then we don't know if it leaves the repository unless we
> > also look at "foo" to see if it is also a symlink. So you really end up
> > having to res
On Wed, Nov 9, 2016 at 5:21 AM, Jeff King wrote:
> On Tue, Nov 08, 2016 at 08:38:55AM +0700, Duy Nguyen wrote:
>
>> > 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
On Tue, Nov 08, 2016 at 08:38:55AM +0700, Duy Nguyen wrote:
> > 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
On Tue, Nov 8, 2016 at 4:15 AM, Jeff King wrote:
> 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
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
On Mon, Nov 07, 2016 at 05:03:42PM +0700, Duy Nguyen wrote:
> On Wed, Nov 2, 2016 at 8:08 PM, Jeff King wrote:
> > The attributes system may sometimes read in-tree files from
> > the filesystem, and sometimes from the index. In the latter
> > case, we do not resolve symbolic links (and are not li
On Wed, Nov 2, 2016 at 8:08 PM, Jeff King wrote:
> The attributes system may sometimes read in-tree files from
> the filesystem, and sometimes from the index. In the latter
> case, we do not resolve symbolic links (and are not likely
> to ever start doing so). Let's open filesystem links with
> O_
The attributes system may sometimes read in-tree files from
the filesystem, and sometimes from the index. In the latter
case, we do not resolve symbolic links (and are not likely
to ever start doing so). Let's open filesystem links with
O_NOFOLLOW so that the two cases behave consistently.
As a bo
15 matches
Mail list logo
