| 4 Apr 2026 |
 emily | well that's vague | 21:29:48 |
 EsperLily [she/her] | vague but it does imply they were accessing up to 4 bytes of the name without checking | 21:30:12 |
| emily | yeah, guess it's probably best to disable the flag after all then | 21:30:19 |
| emily | seems like entirely the wrong place to fix that issue but … | 21:30:26 |
| EsperLily [she/her] | maybe the right solution here is to just copy the same hardeningDisable from vim, it's defined in a common.nix file so it's easy enough to do that | 22:14:43 |
| EsperLily [she/her] | the only risk there is if like, vim upstream fixes the problem and someone removes fortify from that list before macvim itself has been updated, but since it's been there for a decade then that's not very likely | 22:15:42 |
| emily | the Vim package should really be doing just strictflexarrays1 there | 22:25:14 |
| emily | since it was added for a probably-CVE-worthy bug in 2016 and then never adjusted | 22:25:25 |
| emily | and makes any future probably-CVE-worthy bugs more exploitable | 22:25:34 |
| emily | so if MacVim has worked fine without it so far, I wouldn't want to spread the fortify there | 22:25:44 |
| emily | but replacing it with strictflexarrays1 in the Vim package + inheriting that in MacVim sounds sensible | 22:25:54 |
| 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 |
