Make patches relative to where tarballs are extracted

[fosslinux]

Ever since an old patch version, it has (for reasonable security reasons) not supported patched with ../ in the filename. Many of our patches have been relying on this behaviour being OK, because we start off with an ancient patch version that didn't perform such checks. As soon as we need this behaviour after we build a newer patch though, we will have problems.

So, let's change the policy.
Patches are relative to where tarballs are extracted, rather than the "working directory" - e.g. have patches for coreutils-9.4/src/cp.c instead of src/cp.c.
Keeping this consistent has a few implications;

• patches are applied from the build/ directory in bash era now, with -p0
• when patches are manually applied in the bash era, use -p as required, usually -p1
• in kaem era where patches are always manually applied, -p1 is used

[stikonas]

Ever since an old patch version, it has (for reasonable security reasons) not supported patched with ../ in the filename.

Is this documented somewhere? manpage or source? I'm a bit confused here? Are we not allowed to apply patches from parent directory using relative path?

[fosslinux]

Is this documented somewhere?

Not really lol. It is somewhere in the source code (I saw it in safe.c), but can't find it again right now. https://unix.stackexchange.com/a/167250

Are we not allowed to apply patches from parent directory using relative path?

Correct, as of recent-ish patch versions.

Trivial MVP:

x.patch:

--- ../x        2024-12-24 12:24:55.533133606 +1100
+++ ../x        2024-12-24 12:24:43.613133728 +1100
@@ -1 +1 @@
-b
+a

echo b > ../x
patch -Np0 -i x.patch

Will not work on any modern patch version.

[stikonas]

Oh that makes more sense. I was initially thinking about

--- a/x        2024-12-24 12:24:55.533133606 +1100
+++ b/x        2024-12-24 12:24:43.613133728 +1100

and patch file being somewhere above.

patch -Np0 -i ../x.patch

[fosslinux]

Ahh, okay, that is not problematic.