 | Nix on macOS | 1177 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 192 Servers |
| Nix on macOS | 1177 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 192 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Apr 2026 | ||
 emily | IMO if MacVim has been working fine with our default fortification for years then I'd just disable strictflexarrays1 for both and call it a day | 02:29:00 |
| emily | Vim is a CVE magnet so I'd be inclined to risk more potential safe-crashes than exploitable bugs | 02:29:15 |
| emily | but if none have been observed in the accidental experimental group of MacVim users … | 02:29:35 |
| emily | (albeit probably with a tiny sample size) | 02:29:41 |
| emily | the addition of fortify was targeted to one specific bug from 2016 that hadn't yet been fixed upstream so it's only remained out of inertia | 02:30:06 |
 EsperLily [she/her] | yeah ok fair enough. i guess i'll submit two patches, one which switches macvim to using the common hardeningDisable flags and the other which changes that common definition to strictflexarrays1 and let anyone who cares weigh in on it there | 02:31:07 |
| EsperLily [she/her] | i am a little nervous about the comment in the configure script that says that _FORTIFY_SOURCE=2 crashes in gcc 4.0, macvim's been running with fortify but that's always been clang and i don't know if clang vs gcc matters for this today | 02:34:32 |
| emily | I think the fortify behaviour is pretty uniform. but I could be wrong. | 02:37:03 |
| emily | at the time GCC 4.0 was released, Vim was presumably full of exploitable memory safety bugs… | 02:37:18 |
| emily | I imagine a lot more people are running it with hardening flags these days | 02:37:35 |
| emily | would rather have an abort than a 2005-vintage buffer overflow… | 02:38:47 |
| emily | those 2020s commits did imply actual ASAN testing was done at some point at least | 02:38:55 |
| emily | ah, they ASAN in CI even. | 02:39:17 |
| EsperLily [she/her] | the configure script tries to strip any _FORTIFY_SOURCE definition already provided, so anyone who sets it through the environment or CLI will be overridden by vim. nixpkgs handles this inside of cc-wrapper but i assume most distributions don't inject flags by wrapping the compiler in a script | 02:39:30 |
| emily | well, some distros do stuff like patching GCC spec files | 02:40:02 |
| emily | which I think can have a similar effect. (not saying hardening is necessarily done this way0 | 02:40:20 |
| emily | * which I think can have a similar effect. (not saying hardening is necessarily done this way) | 02:40:22 |
| emily | looks like Gentoo specifically tries to inject them in spec files | 02:43:17 |
| EsperLily [she/her] | oooh no with just strictflexarrays1 building on aarch64-linux crashes with "buffer overflow detected" | 03:13:22 |
| EsperLily [she/her] | i wonder if it's worth trying to set the flag depending on which compiler is being used | 03:13:48 |
| EsperLily [she/her] | https://github.com/NixOS/nixpkgs/pull/506844 is the PR for macvim. https://github.com/NixOS/nixpkgs/pull/506853 is the PR for vim, which only changes the flags when using clang. If one PR gets merged, the other will need to be rebased and updated (not super important, but we want to ensure that overriding stdenv on macvim uses that same overridden stdenv for the clang check) | 03:41:03 |
 Randy Eckenrode | I plan to open a PR this week to split the source release sources out from the SDK. The goal is to have the 26.4 SDK in the next staging cycle. | 12:17:44 |
| Randy Eckenrode | After that, we should be able to do SDK updates day 1 once they are available. | 13:09:29 |
| Randy Eckenrode | I plan to add the following packages to the source release list. They will be consumed for their source. Their versions will be from the 14.4 releases to avoid rebuilds. Eventually, I want to build their private headers for use by the other source releases, but they will initially be marked as broken because I do not want to spend any time on that right now. Once it’s done, that will greatly reduce the private header hackery currently required to build source releases.
| 13:16:14 |
| Randy Eckenrode | * I plan to add the following packages to the source release list. They will be consumed for their source. Their versions will be from the 14.4 releases to avoid rebuilds. Eventually, I want to build their private headers for use by the other source releases, but they will initially be marked as broken because I do not want to spend any time on that right now. Once it’s done, that will greatly reduce the private header hackery currently required to build source releases.
| 13:16:23 |
| Randy Eckenrode | * I plan to add the following packages to the source release list. They will be consumed for their source. Their versions will be from the 14.4 releases to avoid rebuilds. Eventually, I want to build their private headers for use by the other source releases, but they will initially be marked as broken because I do not want to spend any time on that right now. Once it’s done, that will greatly reduce the private header hackery currently required to build source releases.
| 13:16:33 |
| Randy Eckenrode | * I plan to add the following packages to the source release list. They will be consumed for their source. Their versions will be from the 14.4 releases to avoid rebuilds. Eventually, I want to build their private headers for use by the other source releases, but they will initially be marked as broken because I do not want to spend any time on that right now. Once it’s done, that will greatly reduce the private header hackery currently required to build source releases.
| 13:16:43 |
| Randy Eckenrode | What I would like to do is not expose them outside the darwin package set, but I don’t want it to be a hassle. I don’t think there’s a good way to do that right now. (I know I can do it with makeScopeWithSplicing’ by adding them to extra, but darwin is not set up to do that in a nice way right now. | 13:18:46 |
 viraptor | Trying to understand the private headers part. Right now they're copied from the private directory to the normal install, like https://github.com/NixOS/nixpkgs/blob/518150a17e5f9505ce45e295d7ce1efc8e69f9ae/pkgs/os-specific/darwin/apple-source-releases/dyld/package.nix#L53 Would they get a separate dev-like package after the change that can be referenced between the built source releases? Or did I misunderstand? | 13:55:55 |
| Randy Eckenrode | That’s it (more or less). XNU, for example, has a build process to produce the headers. | 14:14:42 |