| 4 Apr 2026 |
 emily | as if it was [] | 21:27:28 |
 EsperLily [she/her] | oops | 21:27:42 |
| emily | [] is C99 and [0] is a GNU extension, which are reasons you might avoid those. but [1] is the very conventional thing to use even in non-GNU C89, hence why -fstrict-flex-arrays=1 allows it too, so it's usually just confusing. but yeah maybe disabling the flag is safer in lieu of upstream fixing it. | 21:28:38 |
| emily | I expect they're not actually relying on the [4] for anything if they were under-allocating before 2023, but who can say for sure | 21:29:13 |
| emily | https://github.com/vim/vim/commit/6a12e3342d84a1d754d793ed5019778bd60e7494 | 21:29:35 |
| 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 |
