On August 12, 2019 6:45:40 PM GMT+02:00, Jonathon Fernyhough <[email protected]> wrote: >By default, $HOME is that of the build user. This is usually not a >problem in ephemeral build containers/chroots but can allow some files >to escape into the filesystem where `makepkg` is run outside of a >chroot. > >There can also be instances of generated files (e.g. cache, precompiled >bytecode) being placed into these locations and which are then relied >upon by other parts of the software. > >As a concrete example, Perl6 and nim have a precompilation cache >(though >well-behaved in how it is used). > >`export HOME=/nonexistent` is already used by Debian in their build >tooling and so does not represent a divergence from established >practice. It also allows for badly-behaved build processes to be more >easily spotted and an issue filed upstream where appropriate. > >Signed-off-by: Jonathon Fernyhough <[email protected]> >--- > scripts/makepkg.sh.in | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in >index 43484db3..04edc38a 100644 >--- a/scripts/makepkg.sh.in >+++ b/scripts/makepkg.sh.in >@@ -40,6 +40,8 @@ export COMMAND_MODE='legacy' > unset CDPATH > # Ensure GREP_OPTIONS doesn't screw with our grep calls > unset GREP_OPTIONS >+# Prevent build-user-specific files "escaping" into the filesystem >+export HOME=/nonexistent > > declare -r makepkg_version='@PACKAGE_VERSION@' > declare -r confdir='@sysconfdir@'
Just a side note but Debian has a macro based system that sets vars and options as needed and doesn't require every pkgbuild to handle them case by case. No judgment here, but its not always borken package upstream but this will also have effect on maven, gradle and other generic build systems that will be affected and would be a breaking change that downstream must then incooperate.
