| 5 Apr 2026 |
 EsperLily [she/her] | hmm the commit that introduced it mentioned debian also disabling fortify, the URL it provides doesn't work anymore but I found https://salsa.debian.org/vim-team/vim/-/blob/debian/sid/debian/rules?ref_type=heads#L5-6 which is still turning off fortify and it says that upstream handles the _FORTIFY_SOURCE flag on its own. So I just checked the vim source and there's definitely stuff in there about handling the _FORTIFY_SOURCE flag directly in the configure script, which suggests to me that yeah we should just continue skipping fortify and let vim deal with that itself | 02:08:35 |
 emily | I believe hardeningDisable will actively suppress fortify although I'm not sure. | 02:09:00 |
| emily | I wish we did hardening flags with less indirection | 02:09:19 |
|  artoarto changed their profile picture. | 02:10:36 |
| EsperLily [she/her] | hmm, i don't think so? it looks like hardeningDisable ultimately is just used to remove stuff from the enabledHardeningOptions list, and that turns into the env var NIX_HARDENING_ENABLE. it's possible of course for code to actively suppress any flag not found in that list, but so far i'm not seeing that (e.g. cc-wrapper/add-hardening.sh only takes action on set flags, it doesn't do anything for omitted flags) | 02:17:57 |
| emily | fair enough, I may be wrong then | 02:20:26 |
| emily | note that there are multiple levels of _FORTIFY_SOURCE so Vim could be setting them to inferior ones than us | 02:20:46 |
| emily | and there is no reason to turn it off if our default does not cause issues (which it doesn't, it's strictflexarrays1 that does, so fortify is throwing the baby out with the bathwater somewhat) | 02:21:21 |
| emily | also, I'm not sure disabling fortify will actually disable strictflexarrays1, so certain fortify settings could still trigger it to break | 02:21:58 |
| emily | i.e. even if upstream sets it to something that works without strictflexarrays1, it may break in the presence of our injected strictflexarrays1 | 02:22:12 |
| emily | it looks like Vim will only set -D_FORTIFY_SOURCE=1 and only for GCC? | 02:24:50 |
| emily | unless $GCC is yes in which case uh, it will compare the Clang version to 3 maybe | 02:25:18 |
| emily | what a mess | 02:25:47 |
| EsperLily [she/her] | hmm yeah, this is very messy | 02:28:08 |
| 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 |
