| 7 Oct 2025 |
 dramforever | but this only happens if the executable is built with asan right | 16:17:39 |
| dramforever | otherwise it's just asan compatible | 16:17:58 |
 Vladimír Čunát | Well, it looks like at least the tests in our builds do run with ASAN. | 16:19:03 |
 Grimmauld (any/all) | nether gentoo nor fedora do anything special related to asan | 16:19:11 |
| Vladimír Čunát | * Well, it looks like at least the tests in our audit builds do run with ASAN. | 16:19:14 |
| Grimmauld (any/all) | the whole thing is built with asan, turns out | 16:19:27 |
 dish [Fox/It/She] | https://github.com/nixos/nixpkgs/pull/449548 btw, tested fine for me on x86_64-linux and hexa is working on the aarch builds | 16:31:01 |
| dish [Fox/It/She] | * https://github.com/nixos/nixpkgs/pull/449548 btw, built fine for me on x86_64-linux and hexa is working on the aarch builds | 16:31:18 |
| dish [Fox/It/She] | python 3.13.8 | 16:31:24 |
| Vladimír Čunát | I'm not too fond of redoing darwin stdenvs from scratch, but better now than later, if it should be this staging-next iteration. | 16:33:59 |
| Vladimír Čunát | * I'm not too fond of redoing darwin stdenvs from scratch, but better now than later, if it should be in this staging-next iteration. | 16:34:30 |
| Grimmauld (any/all) | tbh i can't reproduce the issue and i am not familiar enough with pie+asan to judge the impact of just force-disabling asan in audit. unless anyone else has any ideas and/or strong opinions, i'll leave it as is. Willi Butz would you maybe open an upstream issue report? | 16:34:39 |
 Willi Butz | currently trying to repro on a local machine that I just switched to _hardened | 16:35:14 |
| Grimmauld (any/all) | ah 👍️ | 16:35:24 |
| Grimmauld (any/all) | yeah a solid reproducer would be good | 16:35:32 |
| Willi Butz | but please don't block because of some weird setup. if hydra is fine and the tests pass I see no reason for that. I just asked because I couldn't make out why the tests fail ^^ | 16:37:01 |
 K900 | I am rebuilding all of Qt, again | 16:39:01 |
| K900 | HOPEFULLY this is the last one | 16:39:48 |
| dramforever | In reply to @grimmauld:grapevine.grimmauld.de
tbh i can't reproduce the issue and i am not familiar enough with pie+asan to judge the impact of just force-disabling asan in audit. unless anyone else has any ideas and/or strong opinions, i'll leave it as is. Willi Butz would you maybe open an upstream issue report? how about disabling pie | 16:40:32 |
| dramforever | then we go back to what we had in the 25.05 era | 16:40:47 |
| Grimmauld (any/all) | thats also a decent proposal | 16:40:52 |
| Grimmauld (any/all) | i'd probably feel better about that, disabled pie does at least mean probably no runtime crashes of the actual audit userspace | 16:41:28 |
| Grimmauld (any/all) | diff --git a/pkgs/by-name/au/audit/package.nix b/pkgs/by-name/au/audit/package.nix
index 215cda4ba459..71bedbc56352 100644
--- a/pkgs/by-name/au/audit/package.nix
+++ b/pkgs/by-name/au/audit/package.nix
@@ -75,6 +75,9 @@ stdenv.mkDerivation (finalAttrs: {
libcap_ng
];
+ # audit is built with asan, and asan breaks with pie on some kernels
+ hardeningDisable = [ "pie" ];
+
configureFlags = [
# z/OS plugin is not useful on Linux, and pulls in an extra openldap
# dependency otherwise
Willi Butz could you try this one too maybe (on the machine that breaks)?
| 16:43:15 |
| Willi Butz | sure | 16:43:31 |
| Grimmauld (any/all) | sorry to make you do the testing, but as long as you have a machine that reproduces i am afraid code-pingpong will be necessary | 16:44:03 |
 Lun | that won't do anything, the hardening flag is dysfunctional and pending removal :/ | 16:44:39 |
| Lun | NIX_CFLAGS_COMPILE no-pie or something | 16:44:49 |
| Grimmauld (any/all) | oh no | 16:44:49 |
| dramforever | wait, how did that happen | 16:45:06 |
| Grimmauld (any/all) | won't that break a bunch of shit? | 16:45:29 |
