| 4 Apr 2026 |
 emily | heh, that or our Vim package has just had hardeningDisable = [ "fortify" ]; since 2016 🙃 | 21:12:12 |
| emily | actually since earlier. guessing that's very much not necessary these days | 21:12:39 |
| emily | (actually no 2016 is right, but it was earlier in 2016 than I thought) | 21:13:06 |
| emily |
Fortify hardening detects a probable buffer overflow in vim at runtime. This has to be fixed upstream.
reassuring commit messages…
| 21:13:22 |
 EsperLily [she/her] | is this the right flag to disable for this, or is there a more targeted flag that will do it? | 21:22:48 |
| emily | strictflexarrays1 is more targeted, but it's also a one byte fix to https://github.com/vim/vim/blob/master/src/structs.h#L2017-L2019 to avoid the issue entirely | 21:25:00 |
| emily | https://github.com/vim/vim/blob/5943c57173e78ce5b5d82d3e908542b010a31134/src/userfunc.c#L723 even goes bizarrely out of its way to avoid depending on the size | 21:25:22 |
| emily | not sure why they're even doing [4] in the first place | 21:26:02 |
| EsperLily [she/her] | yeah, i just have to wonder why it is defined as [4] and so whether there's any code elsewhere that assumes it's always at least 4 bytes | 21:26:06 |
| EsperLily [she/her] | my best guess is they want to be able to just compare the first 4 bytes to look for special patterns without having to check if it even has 4 bytes of name | 21:26:24 |
| emily | usually it's more about padding out the size of the struct from what I've seen, but rarely with any justification of why they'd want to do that | 21:26:54 |
| EsperLily [she/her] | which i guess they could do by declaring it as [] or [0] and then adding the minimum 4 in alloc_ufunc too | 21:26:57 |
| emily | https://github.com/vim/vim/commit/e01e5215f927f83778ad7494abb0007aa52d08c3 it already got them in hot water with ASAN | 21:27:04 |
| emily | because they were under-allocating | 21:27:23 |
| 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 |
