[vim/vim] Modelines cause too many issues (PR #19875)

Christian Brabandt

unread,

Mar 31, 2026, 11:34:27 AM (yesterday) Mar 31

to vim/vim, Subscribed

Problem: Modelines cause too many issues
Solution: Disable modeline by default

Note: this is a slightly backwards incompatible change.

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/19875

Commit Summary

1a50fa1 Modelines cause too many issues

File Changes

(4 files)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

MURAOKA Taro

unread,

Mar 31, 2026, 9:07:25 PM (24 hours ago) Mar 31

to vim/vim, Subscribed

koron left a comment (vim/vim#19875)

After this change, many Vim users, including myself, will probably add set modeline to their .vimrc file. If that happens, it becomes unclear whether this can still be considered a security measure.

As an alternative, I propose changing the system so that all options are initially marked as incompatible with modeline, and then clearly safe options are re-marked as compatible with modeline one by one. Currently, we use a blacklist approach to specify options that cannot be used with modeline, but going forward, we will use a whitelist approach to specify options that can be used with modeline.

I think it's acceptable for all options to be temporarily unavailable in modeline during that process. Alternatively, the initial change could involve registering only the options used in modeline in the vim source code to the whitelist.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

BenYip

unread,

2:45 PM (6 hours ago) 2:45 PM

to vim/vim, Subscribed

bennyyip left a comment (vim/vim#19875)

What exactly is "too many issues"? I know there is a recent modeline security bug(GHSA-2gmj-rpqf-pxvh). Is there anything else?

I agree with the whitelist approach. Here is a list of common options that should be safe:

autoindent
colorcolumn
commentstring
conceallevel
expandtab
fileencoding
filetype
foldenable
foldlevel
foldmarker
foldmethod
modifiable
readonly
rightleft
shiftwidth
softtabstop
tabstop
varsofttabstop

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Brian Inglis

unread,

5:40 PM (3 hours ago) 5:40 PM

to vim/vim, Subscribed

BrianInglis left a comment (vim/vim#19875)

A lot of programmers use various editor (eclipse, emacs, gedit, Kate, VScode, Zed) modelines where supported, as many text files have syntax not recognized as unique MIME types, suffixes, by vim, or maybe also language scripts which need alternate writing directions, especially for comments?
Security should be enhanced for those, but any and all changes should be documented thoroughly and preannounced as deprecated, before dis-/enabling the new features in succeeding release(s).
Perhaps some new approach(es) should also be supported, like other editors' modelines for compatibility, or EditorConfig features, but including support in command line versions, where to my mind modelines supported features previously commonly available only with GUIs.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

James McCoy

unread,

5:50 PM (3 hours ago) 5:50 PM

to vim/vim, Subscribed

jamessan left a comment (vim/vim#19875)

FWIW, Debian Vim packages have defaulted to 'nomodeline' for 20 years, and also recommended vim-securemodelines as an way to allow list modelines (with an opinionated builtin list).

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward