On Tue, 27 Jan 2015 15:47:04 +, Andreas Gruenbacher wrote:
> On Mon, 26 Jan 2015 13:50:10 -0800, Linus Torvalds wrote:
>> I _think_ we allow arbitrary symlinks to be created, but then we should
>> be careful about actually _following_ them.
>
> I would prefer to allow arbitrary symlinks even
On Tue, 27 Jan 2015 15:47:04 +, Andreas Gruenbacher wrote:
On Mon, 26 Jan 2015 13:50:10 -0800, Linus Torvalds wrote:
I _think_ we allow arbitrary symlinks to be created, but then we should
be careful about actually _following_ them.
I would prefer to allow arbitrary symlinks even in GNU
Junio C Hamano writes:
> Subject: [PATCH] apply: refuse touching a file beyond symlink
>
> Because Git tracks symbolic links as symbolic links, a path that has
> a symbolic link in its leading part (e.g. path/to/dir being a
> symbolic link to somewhere else, be it inside or outside the working
>
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> If the user wants to apply a patch that touches ../etc/shadow, is
>> the tool in the place to complain?"
>
> Let me take this part back.
>
> I think "git apply" should behave closely to "git apply --index"
> (which is used by "git am" unless
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
If the user wants to apply a patch that touches ../etc/shadow, is
the tool in the place to complain?
Let me take this part back.
I think git apply should behave closely to git apply --index
(which is used
Junio C Hamano gits...@pobox.com writes:
Subject: [PATCH] apply: refuse touching a file beyond symlink
Because Git tracks symbolic links as symbolic links, a path that has
a symbolic link in its leading part (e.g. path/to/dir being a
symbolic link to somewhere else, be it inside or outside
Junio C Hamano writes:
> Linus Torvalds writes:
>
>> Ugh. I don't see anything we can do about this on the git side, and I
>> do kind of understand why 'patch' would be worried about '..' files.
>> In a perfect world, patch would parse the filename and see that it
>> stays within the directory
On Mon, 26 Jan 2015 13:50:10 -0800, Linus Torvalds wrote:
> On Mon, Jan 26, 2015 at 1:35 PM, Junio C Hamano
> wrote:
>>
>> What is your take on CVE-2015-1196, which brought this /regression/ to
>> GNU patch?
>> If "git apply" get /fixed/ for that same CVE, would that /break/ your
>> fix?
>
> I
On Mon, 26 Jan 2015 12:44:33 -0800, Linus Torvalds wrote:
> I've considered that for a while already, because "patch" _does_ kind of
> understand them these days, although I think it gets the cross-rename
> case wrong because it fundamentally works on a file-by-file basis.
Patch handles
Junio C Hamano gits...@pobox.com writes:
Linus Torvalds torva...@linux-foundation.org writes:
Ugh. I don't see anything we can do about this on the git side, and I
do kind of understand why 'patch' would be worried about '..' files.
In a perfect world, patch would parse the filename and see
On Mon, 26 Jan 2015 13:50:10 -0800, Linus Torvalds wrote:
On Mon, Jan 26, 2015 at 1:35 PM, Junio C Hamano gits...@pobox.com
wrote:
What is your take on CVE-2015-1196, which brought this /regression/ to
GNU patch?
If git apply get /fixed/ for that same CVE, would that /break/ your
fix?
I
On Mon, 26 Jan 2015 12:44:33 -0800, Linus Torvalds wrote:
I've considered that for a while already, because patch _does_ kind of
understand them these days, although I think it gets the cross-rename
case wrong because it fundamentally works on a file-by-file basis.
Patch handles cross-renames
Linus Torvalds writes:
> Ugh. I don't see anything we can do about this on the git side, and I
> do kind of understand why 'patch' would be worried about '..' files.
> In a perfect world, patch would parse the filename and see that it
> stays within the directory structure of the project, but
On Mon, Jan 26, 2015 at 4:30 PM, Linus Torvalds
wrote:
> On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer wrote:
>>
>> Or did I miss a way that git-apply can take a git patch and apply it
>> to a tree that isn't a git repo?
>
> Exactly. "git apply" works as a straight "patch" replacement outside
> of
On Mon, Jan 26, 2015 at 1:35 PM, Junio C Hamano wrote:
>
> What is your take on CVE-2015-1196, which brought this /regression/ to
> GNU patch?
> If "git apply" get /fixed/ for that same CVE, would that /break/ your fix?
I _think_ we allow arbitrary symlinks to be created, but then we
should be
On Mon, Jan 26, 2015 at 1:30 PM, Linus Torvalds
wrote:
> On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer wrote:
>>
>> Or did I miss a way that git-apply can take a git patch and apply it
>> to a tree that isn't a git repo?
>
> Exactly. "git apply" works as a straight "patch" replacement outside
> of
On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer wrote:
>
> Or did I miss a way that git-apply can take a git patch and apply it
> to a tree that isn't a git repo?
Exactly. "git apply" works as a straight "patch" replacement outside
of a git repository. It doesn't actually need a git tree to work.
On Mon, Jan 26, 2015 at 3:44 PM, Linus Torvalds
wrote:
> On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer wrote:
>>
>> I went to do the Fedora 3.19-rc6 build this morning and it failed in
>> our buildsystem with:
>>
>> + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
>> + case "$patch" in
Linus Torvalds writes:
> On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer wrote:
>>
>> I went to do the Fedora 3.19-rc6 build this morning and it failed in
>> our buildsystem with:
>>
>> + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
>> + case "$patch" in
>> + unxz
>> + patch -p1 -F1 -s
On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer wrote:
>
> I went to do the Fedora 3.19-rc6 build this morning and it failed in
> our buildsystem with:
>
> + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
> + case "$patch" in
> + unxz
> + patch -p1 -F1 -s
> symbolic link target
[Adding Junio's correct email address. Sigh.]
On Mon, Jan 26, 2015 at 11:29 AM, Josh Boyer wrote:
> Hi,
>
> I went to do the Fedora 3.19-rc6 build this morning and it failed in
> our buildsystem with:
>
> + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
> + case "$patch" in
> + unxz
>
Hi,
I went to do the Fedora 3.19-rc6 build this morning and it failed in
our buildsystem with:
+ '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
+ case "$patch" in
+ unxz
+ patch -p1 -F1 -s
symbolic link target '../../../../../include/dt-bindings' is invalid
error: Bad exit status from
[Adding Junio's correct email address. Sigh.]
On Mon, Jan 26, 2015 at 11:29 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
Hi,
I went to do the Fedora 3.19-rc6 build this morning and it failed in
our buildsystem with:
+ '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
+ case
Hi,
I went to do the Fedora 3.19-rc6 build this morning and it failed in
our buildsystem with:
+ '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
+ case $patch in
+ unxz
+ patch -p1 -F1 -s
symbolic link target '../../../../../include/dt-bindings' is invalid
error: Bad exit status from
On Mon, Jan 26, 2015 at 4:30 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
Or did I miss a way that git-apply can take a git patch and apply it
to a tree that isn't a git repo?
Exactly. git apply works as
On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
I went to do the Fedora 3.19-rc6 build this morning and it failed in
our buildsystem with:
+ '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
+ case $patch in
+ unxz
+ patch -p1 -F1 -s
symbolic link
On Mon, Jan 26, 2015 at 1:35 PM, Junio C Hamano gits...@pobox.com wrote:
What is your take on CVE-2015-1196, which brought this /regression/ to
GNU patch?
If git apply get /fixed/ for that same CVE, would that /break/ your fix?
I _think_ we allow arbitrary symlinks to be created, but then we
Linus Torvalds torva...@linux-foundation.org writes:
On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
I went to do the Fedora 3.19-rc6 build this morning and it failed in
our buildsystem with:
+ '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']'
+ case
On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
Or did I miss a way that git-apply can take a git patch and apply it
to a tree that isn't a git repo?
Exactly. git apply works as a straight patch replacement outside
of a git repository. It doesn't actually need a
On Mon, Jan 26, 2015 at 3:44 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
I went to do the Fedora 3.19-rc6 build this morning and it failed in
our buildsystem with:
+ '[' '!' -f
On Mon, Jan 26, 2015 at 1:30 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
Or did I miss a way that git-apply can take a git patch and apply it
to a tree that isn't a git repo?
Exactly. git apply works as
Linus Torvalds torva...@linux-foundation.org writes:
Ugh. I don't see anything we can do about this on the git side, and I
do kind of understand why 'patch' would be worried about '..' files.
In a perfect world, patch would parse the filename and see that it
stays within the directory
32 matches
Mail list logo
