Re: nasty patches in pkgsrc regarding CVE-2010-4651: relative paths with ../

--00000000000015eea70655b92e75
Content-Type: text/plain; charset="UTF-8"

On Fri, 3 Jul 2026 at 10:15, Greg Troxel <[email protected]> wrote:

> Alistair Crooks <[email protected]> writes:
>
> >> 2) Add patches-wrkdir *additionally* for patches based on wrkdir.  Teach
> >> mkpatches to put patches within WRKSRC in patches, and other patches in
> >> patches-wrkdir
> >>
> >
> > I'm still not sure this is a good idea :(
> >
> > But I do agree that relative paths in patch files, all 180+ of them,
> should
> > not exist. Good catch
>
> I'm not sure either.
>
> What is your approach?
>

I've not really thought about it, and real life has intrudded today, but...

I'd be inclined to add a directory under ${WRKDIR} in places where relative
patches would occur - in the Makefile as WRKSRC_INDIRECT or similar.
Normally this directory name would not be needed, so the default case is
blank. I'd introduce an internal  _PATCHBASE variable to set the directory
to use as the root for patching, depending upon WRKSRC_INDIRECT. Adjust
mkpatches as necessary. Add a pkglint check for relative directories in
patch files.

However, I haven't tried any of this, so I've no idea whether it would fly,
or what the corner cases are.

In general, the idea is to only patch under WRKSRC, introduce as few
complications and/or unnecessaries as possible, and don't allow relative
patches.

Best,
Al

--00000000000015eea70655b92e75
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 3 Jul 2=
026 at 10:15, Greg Troxel &lt;<a href=3D"mailto:[email protected]">gdt@lexort.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Alistair Crooks &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt; writes:<br>
<br>
&gt;&gt; 2) Add patches-wrkdir *additionally* for patches based on wrkdir.=
=C2=A0 Teach<br>
&gt;&gt; mkpatches to put patches within WRKSRC in patches, and other patch=
es in<br>
&gt;&gt; patches-wrkdir<br>
&gt;&gt;<br>
&gt;<br>
&gt; I&#39;m still not sure this is a good idea :(<br>
&gt;<br>
&gt; But I do agree that relative paths in patch files, all 180+ of them, s=
hould<br>
&gt; not exist. Good catch<br>
<br>
I&#39;m not sure either.<br>
<br>
What is your approach?<br></blockquote><div><br></div><div>I&#39;ve not rea=
lly thought about it, and real life has intrudded=C2=A0today, but...</div><=
div><br></div><div>I&#39;d be inclined to add a directory under ${WRKDIR} i=
n places where relative patches would occur - in the Makefile as WRKSRC_IND=
IRECT or similar. Normally this directory name would not be needed, so the =
default case is blank. I&#39;d introduce an internal=C2=A0 _PATCHBASE varia=
ble to set the directory to use as the root for patching, depending upon WR=
KSRC_INDIRECT. Adjust mkpatches=C2=A0as necessary. Add a pkglint=C2=A0check=
 for relative=C2=A0directories in patch files.</div><div><br></div><div>How=
ever, I haven&#39;t tried any of this, so I&#39;ve no idea whether it would=
 fly, or what the corner cases are.</div><div><br></div><div>In general, th=
e idea is to only patch under WRKSRC, introduce as few complications and/or=
 unnecessaries as possible, and don&#39;t allow relative patches.</div><div=
><br></div><div>Best,</div><div>Al</div></div></div>

--00000000000015eea70655b92e75--