It won't work in the devtools containers without this. You could use NoExtract to get rid of that file.

Why not just put the path override in relevant PKGBUILDS or split the package (or patch makepkg and add a harden option)?

> or patch makepkg and add a harden option

I already tried this approach and there wasn't interest in landing patches for stuff like this. I switched to injecting it into PATH as a fallback plan.

> Why not just put the path override in relevant PKGBUILDS

The primary use case is fixing packages ignoring CFLAGS/LDFLAGS without needing to delve into modifying their build system. There are already 8 packages using it for this and they would need to be changed. Some of them are in [extra] so I can't do it myself.

> The hardening wrappers don't always work (I've had some problems building rust) and can be fairly slow however

It should always work, and you should file a bug if there's a case where it breaks.

> and can be fairly slow however

PIE on x86_64 and RELRO don't have a measurable performance cost. The stack protector does, but it's simple enough to disable it via the environment variable. The long-term goal is for binutils and GCC to have support for using hardening options by default, and Arch would then enable it to replace the hardening switches used in the default CFLAGS/LDFLAGS. I expect the RELRO support to land upstream soon, and one of the GCC committers is trying to land PIE by default support.

> I still want to use them to build some packages

Add it as a make dependency and use the clean building mechanism (devtools) used to build official packages. I don't really understand the problem though, since this is going to be the behaviour of our vanilla toolchain in the future.

>> or patch makepkg and add a harden option

> I already tried this approach and there wasn't interest in landing patches for stuff like this. I switched to injecting it into PATH as a fallback plan.

That's rather annoying (considering that ccache and discc are already supported.

>> Why not just put the path override in relevant PKGBUILDS

> The primary use case is fixing packages ignoring CFLAGS/LDFLAGS without needing to delve into modifying their build system. There are already 8 packages using it for this and they would need to be changed. Some of them are in [extra] so I can't do it myself.

1. I didn't suggest modifying their build system, just the PKGBUILD.
2. Packages can always be fixed.
3. If you split the package into hardening-wrapper containing the path override and hardening-wrapper-bin (or -core, etc.) containing the scripts, nothing will break and people who don't want their toolchain messed with behind their backs will be happy (this "feature" was added to the hardening-wrapper scripts fairly recently).

>> The hardening wrappers don't always work (I've had some problems building rust) and can be fairly slow however

> It should always work, and you should file a bug if there's a case where it breaks.

You're right, it was another bug (the hardening wrappers don't play well with ccache).

>> and can be fairly slow however
> PIE on x86_64 and RELRO don't have a measurable performance cost. The stack protector does, but it's simple enough to disable it via the environment variable. The long-term goal is for binutils and GCC to have support for using hardening options by default, and Arch would then enable it to replace the hardening switches used in the default CFLAGS/LDFLAGS. I expect the RELRO support to land upstream soon, and one of the GCC committers is trying to land PIE by default support.

I meant compile-time. However, in retrospect, this might just have been a manifestation of the above bug (compilation would hang and I just assumed that it was just taking a really long time).

>> I still want to use them to build some packages

> Add it as a make dependency and use the clean building mechanism (devtools) used to build official packages. I don't really understand the problem though, since this is going to be the behaviour of our vanilla toolchain in the future.

makepkg is supposed to work without a clean build environment and packages shouldn't magically patch themselves into makepkg. As for the second statement, last time I checked the discussion of whether or not the hardening-wrappers will be used is on-going.

> As for the second statement, last time I checked the discussion of whether or not the hardening-wrappers will be used is on-going.

I said it's going to be the behaviour of the vanilla toolchain in the future, as in wrappers won't be required. That's why I mentioned the pending RELRO and PIE patches.

I don't mind splitting out the profile.d script.

Oh. Sorry, I thought you were referring to https://lists.archlinux.org/pipermail/arch-dev-public/2014-December/026843.html. Regardless, I apologize, I've overreacted by quite a large margin; feel free to do what you think is best.

Story: I recently tried to rebuild mpv which pulled in the hardening wrapper. The mpv build succeeded because I didn't log out and back in (didn't source my profile) but several subsequent builds of other packages failed because of the ccache+hardening-wrapper bug and I (incorrectly) assumed that these packages were simply incompatible with the hardening wrapper. I still don't think packages should automatically override binaries provided by another package but I understand why you did it in this case. Sorry to be such a pain and thanks for bearing with me.

The actual bug: https://github.com/thestinger/hardening-wrapper/issues/2

Steven: See https://bugs.archlinux.org/task/43224

Got it. I searched for open bugs but didn't think about searching for closed ones. I had enable ccache twice... (makepkg and my path).