FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-30-2010, 11:04 PM
Mike Frysinger
 
Default epatch: reject patches with relative paths

epatch was changed to auto-skip the first path element when it is absolute
(starts with a slash). the reason was to avoid issues with patches touching
files outside of $PWD (which is bad if sandbox is disabled).

along those lines, we should start rejecting relative paths. we cant auto-
skip the leading elements since relative paths could appear anywhere.

rather than making it fatal right away, this patch adds some ewarns. after a
while, we can convert it to a die.
-mike

--- eutils.eclass 22 Nov 2010 00:31:03 -0000 1.352
+++ eutils.eclass 30 Dec 2010 23:52:41 -0000
@@ -360,6 +360,12 @@ epatch() {
count=1
printf "NOTE: skipping -p0 due to absolute paths in patch:
%s
" "${abs_paths}" >> "${STDERR_TARGET}"
fi
+ # Similar reason, but with relative paths.
+ local rel_paths=$(egrep -n '^[-+]{3} [^ ]*[.][.]/' "${PATCH_TARGET}")
+ if [[ -n ${rel_paths} ]] ; then
+ ewarn "Your patch has relative paths; in the future this will fail:"
+ ewarn "${rel_paths}"
+ fi

# Dynamically detect the correct -p# ... i'm lazy, so shoot me :/
while [[ ${count} -lt 5 ]] ; do
 
Old 12-30-2010, 11:42 PM
"Robin H. Johnson"
 
Default epatch: reject patches with relative paths

On Thu, Dec 30, 2010 at 07:04:25PM -0500, Mike Frysinger wrote:
> epatch was changed to auto-skip the first path element when it is absolute
> (starts with a slash). the reason was to avoid issues with patches touching
> files outside of $PWD (which is bad if sandbox is disabled).
+1 from me, but can we have a QA prefix on the ewarn output?

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
 
Old 12-31-2010, 12:05 AM
Enrico Weigelt
 
Default epatch: reject patches with relative paths

* Robin H. Johnson <robbat2@gentoo.org> schrieb:
> On Thu, Dec 30, 2010 at 07:04:25PM -0500, Mike Frysinger wrote:
> > epatch was changed to auto-skip the first path element when it is absolute
> > (starts with a slash). the reason was to avoid issues with patches touching
> > files outside of $PWD (which is bad if sandbox is disabled).
> +1 from me, but can we have a QA prefix on the ewarn output?

IMHO, in longer terms, all patches should normalized, created w/
diff -ruN and applied w/ -p1. Thats how most people do it, so
a kind of semi-standard.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
 
Old 12-31-2010, 12:26 AM
Mike Frysinger
 
Default epatch: reject patches with relative paths

On Thursday, December 30, 2010 20:05:01 Enrico Weigelt wrote:
> IMHO, in longer terms, all patches should normalized, created w/
> diff -ruN and applied w/ -p1. Thats how most people do it, so
> a kind of semi-standard.

not worth developer's time to force it since it poses no practical positive
benefit to us
-mike
 
Old 12-31-2010, 12:28 AM
Mike Frysinger
 
Default epatch: reject patches with relative paths

On Thursday, December 30, 2010 19:42:35 Robin H. Johnson wrote:
> On Thu, Dec 30, 2010 at 07:04:25PM -0500, Mike Frysinger wrote:
> > epatch was changed to auto-skip the first path element when it is
> > absolute (starts with a slash). the reason was to avoid issues with
> > patches touching files outside of $PWD (which is bad if sandbox is
> > disabled).
>
> +1 from me, but can we have a QA prefix on the ewarn output?

--- eutils.eclass 22 Nov 2010 00:31:03 -0000 1.352
+++ eutils.eclass 31 Dec 2010 01:28:37 -0000
@@ -360,6 +360,13 @@ epatch() {
count=1
printf "NOTE: skipping -p0 due to absolute paths in patch:
%s
" "${abs_paths}" >> "${STDERR_TARGET}"
fi
+ # Similar reason, but with relative paths.
+ local rel_paths=$(egrep -n '^[-+]{3} [^ ]*[.][.]/' "${PATCH_TARGET}")
+ if [[ -n ${rel_paths} ]] ; then
+ eqawarn "QA Notice: Your patch has relative paths."
+ eqawarn " In the future this will cause a failure."
+ eqawarn "${rel_paths}"
+ fi

# Dynamically detect the correct -p# ... i'm lazy, so shoot me :/
while [[ ${count} -lt 5 ]] ; do
-mike
 
Old 12-31-2010, 01:01 AM
Markos Chandras
 
Default epatch: reject patches with relative paths

On Thu, Dec 30, 2010 at 08:28:42PM -0500, Mike Frysinger wrote:
> On Thursday, December 30, 2010 19:42:35 Robin H. Johnson wrote:
> > On Thu, Dec 30, 2010 at 07:04:25PM -0500, Mike Frysinger wrote:
> > > epatch was changed to auto-skip the first path element when it is
> > > absolute (starts with a slash). the reason was to avoid issues with
> > > patches touching files outside of $PWD (which is bad if sandbox is
> > > disabled).
> >
> > +1 from me, but can we have a QA prefix on the ewarn output?
>
> --- eutils.eclass 22 Nov 2010 00:31:03 -0000 1.352
> +++ eutils.eclass 31 Dec 2010 01:28:37 -0000
> @@ -360,6 +360,13 @@ epatch() {
> count=1
> printf "NOTE: skipping -p0 due to absolute paths in patch:
%s
" "${abs_paths}" >> "${STDERR_TARGET}"
> fi
> + # Similar reason, but with relative paths.
> + local rel_paths=$(egrep -n '^[-+]{3} [^ ]*[.][.]/' "${PATCH_TARGET}")
> + if [[ -n ${rel_paths} ]] ; then
> + eqawarn "QA Notice: Your patch has relative paths."
> + eqawarn " In the future this will cause a failure."
> + eqawarn "${rel_paths}"
> + fi
>
> # Dynamically detect the correct -p# ... i'm lazy, so shoot me :/
> while [[ ${count} -lt 5 ]] ; do
> -mike

Mike,

Maybe we should open a tracker to identify which packages use relative paths
in their patches before making this control check fatal.

Regards,
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
 
Old 12-31-2010, 01:03 AM
Enrico Weigelt
 
Default epatch: reject patches with relative paths

* Mike Frysinger <vapier@gentoo.org> schrieb:
> On Thursday, December 30, 2010 20:05:01 Enrico Weigelt wrote:
> > IMHO, in longer terms, all patches should normalized, created w/
> > diff -ruN and applied w/ -p1. Thats how most people do it, so
> > a kind of semi-standard.
>
> not worth developer's time to force it since it poses no practical positive
> benefit to us

It makes it easier for everyone who'll want to work on these
patches (eg. people besides the actual ebuild maintainers).

BTW: I'm not proposing to rework all the patches right now,
just set a policy for new ones.

Even you might not like to hear this, Debian is much better at this
point - they a patchqueue per each package, which can be applied
fully automatically (w/o additional code in the invididual package
descriptors). This allows easy importing into other systems
(like I'm doing w/ my normalized git repositories within the
oss-qm project).


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
 
Old 12-31-2010, 01:05 AM
"Jory A. Pratt"
 
Default epatch: reject patches with relative paths

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/30/2010 07:28 PM, Mike Frysinger wrote:
> On Thursday, December 30, 2010 19:42:35 Robin H. Johnson wrote:
>> On Thu, Dec 30, 2010 at 07:04:25PM -0500, Mike Frysinger wrote:
>>> epatch was changed to auto-skip the first path element when it is
>>> absolute (starts with a slash). the reason was to avoid issues with
>>> patches touching files outside of $PWD (which is bad if sandbox is
>>> disabled).
>>
>> +1 from me, but can we have a QA prefix on the ewarn output?
>
> --- eutils.eclass 22 Nov 2010 00:31:03 -0000 1.352
> +++ eutils.eclass 31 Dec 2010 01:28:37 -0000
> @@ -360,6 +360,13 @@ epatch() {
> count=1
> printf "NOTE: skipping -p0 due to absolute paths in patch:
%s
" "${abs_paths}" >> "${STDERR_TARGET}"
> fi
> + # Similar reason, but with relative paths.
> + local rel_paths=$(egrep -n '^[-+]{3} [^ ]*[.][.]/' "${PATCH_TARGET}")
> + if [[ -n ${rel_paths} ]] ; then
> + eqawarn "QA Notice: Your patch has relative paths."
> + eqawarn " In the future this will cause a failure."
> + eqawarn "${rel_paths}"
> + fi
>
> # Dynamically detect the correct -p# ... i'm lazy, so shoot me :/
> while [[ ${count} -lt 5 ]] ; do
> -mike
+1 from me!!!

- --
================================================== ====
Jory A. Pratt anarchy -at- gentoo.org
Gentoo Mozilla Lead
GPG: 2C1D 6AF9 F35D 5122 0E8F 9123 C270 3B43 5674 6127
================================================== ====

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0dOmEACgkQwnA7Q1Z0YSfEHwCgrI5PjbcIPB sCh2yzcTPa1gxf
+1AAn2w97jB4wYKo/k69jS6wj5wPfcPW
=tJ2w
-----END PGP SIGNATURE-----
 
Old 12-31-2010, 04:17 AM
Mike Frysinger
 
Default epatch: reject patches with relative paths

On Thursday, December 30, 2010 21:03:54 Enrico Weigelt wrote:
> * Mike Frysinger <vapier@gentoo.org> schrieb:
> > On Thursday, December 30, 2010 20:05:01 Enrico Weigelt wrote:
> > > IMHO, in longer terms, all patches should normalized, created w/
> > > diff -ruN and applied w/ -p1. Thats how most people do it, so
> > > a kind of semi-standard.
> >
> > not worth developer's time to force it since it poses no practical
> > positive benefit to us
>
> It makes it easier for everyone who'll want to work on these
> patches (eg. people besides the actual ebuild maintainers).
>
> BTW: I'm not proposing to rework all the patches right now,
> just set a policy for new ones.

suggestions are fine, but these arent a requirement we're going to force on
developers. i already put together a list of suggestions for people long ago:
http://dev.gentoo.org/~vapier/clean-patches

> Even you might not like to hear this, Debian is much better at this
> point

i could care less

> they a patchqueue per each package, which can be applied
> fully automatically (w/o additional code in the invididual package
> descriptors).

it'd be trivial to do the same thing in Gentoo, but it doesnt make sense.
Debian doesnt maintain a unified package tree of multiple versions.
-mike
 
Old 12-31-2010, 04:20 AM
Mike Frysinger
 
Default epatch: reject patches with relative paths

On Thursday, December 30, 2010 21:01:49 Markos Chandras wrote:
> On Thu, Dec 30, 2010 at 08:28:42PM -0500, Mike Frysinger wrote:
> > + eqawarn "QA Notice: Your patch has relative paths."
> > + eqawarn " In the future this will cause a failure."
>
> Maybe we should open a tracker to identify which packages use relative
> paths in their patches before making this control check fatal.

sounds like overkill. people will file bugs and they'll get fixed. once it
goes fatal, people will fix even faster. i dont plan on making it fatal
anytime soon.

a simple grep of in tree patches shows only a handful of hits.
-mike
 

Thread Tools




All times are GMT. The time now is 11:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org