On August 12, 2019 12:45:40 PM EDT, Jonathon Fernyhough 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.

I don't understand why you think it's a good idea to quarantine makepkg from knowing where HOME is, when makepkg is one of the things that needs to read a file from HOME. That is to say, your patch will break reading $HOME/.makepkg.conf, and also break reading $HOME/.config/pacman/makepkg.conf if $XDG_CONFIG_HOME is unset. But that raises the point that your patch also doesn't actually quarantine makepkg from knowing where XDG-respecting programs store and write to their content. More generally, your patch is trying to solve the problem for which we've always said "well, uh, that's why build chroots exist". What would you like to unset next? /usr/local PATH=$HOME/bin:$PATH General variables defined in bashrc based on HOME, but now containing hardcodes paths? Maybe we should do full environment cleaning. Maybe we should just implement a systemd-nspawn wrapper directly in makepkg. ... Or we can continue as we do today. makepkg provides build orchestration, and makechrootpkg provides isolation. -- Eli Schwartz Bug Wrangler and Trusted User