Problem: Cannot set 'path' option via modeline (zeertzjq, after v9.2.0435)
Solution: Revert the part that disallows setting 'path' via modeline.
closes: vim/vim#2013788fb739918
Co-authored-by: Christian Brabandt <cb@256bit.org>
(cherry picked from commit d1c3d6fbaa)
Problem: [security]: Backticks enclosed shell commands in the 'path'
option value are executed during completion (q1uf3ng).
Solution: Skip path entries containing backticks, add P_SECURE to 'path'
option, so that it cannot be set from a modeline (for symmetry with
the 'cdpath' option)
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-hwg5-3cxw-wvvg
Supported by AI.
190cb3c2b9
Co-authored-by: Christian Brabandt <cb@256bit.org>
(cherry picked from commit b06f8b174f)
Problem: tests: test_modeline.vim fails (after v9.2.0276)
Solution: Rewrite the tests to use the existing s:modeline_fails()
function, update documentation (zeertzjq).
8c8772c6b3
(cherry picked from commit 65e2218585)
Problem: Option insecure flags not copied when splitting window.
Solution: Move window-local insecure flags to winopt_T and copy them
properly (zeertzjq).
closes: vim/vim#18434b3740f4b00
Problem: :set doesn't clear local insecure flag like :setlocal does.
Solution: Also clear the local insecure flag when using :set (zeertzjq).
This applies to local options like 'wrap', 'foldtext' and 'foldexpr',
whose global flags are actually never used. For global-local options
like 'statusline' the behavior is already correct, so add some tests.
related: vim/vim#18434fec5586a45
Problem: 'nowrap' in a modeline may hide malicious code.
Solution: Forcibly use '>' as 'listchars' "extends" if 'nowrap' was set
from a modeline (zeertzjq).
Manual `:setlocal nowrap` disables this behavior. There is a separate
problem with `:set nowrap` that also applies to some other options.
related: vim/vim#18214
related: vim/vim#18399closes: vim/vim#184259d5208a931
Cherry-pick some test_modeline.vim changes from patches 9.0.{0363,0626}.
Problem: 'findexpr' can't be used for lambads
(Justin Keyes)
Solution: Replace the findexpr option with the findfunc option
(Yegappan Lakshmanan)
related: vim/vim#15905closes: vim/vim#15976a13f3a4f5d
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters
statusline fillchar may be different than expected
If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window). I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.
However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.
So, let's assume users know what they are doing and just always return
the configured stl and stlnc values. And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it. It
is their responsibility and Vim shall not know better what to use.
fixes: vim/vim#13366closes: vim/vim#134886a650bf696
Co-authored-by: Christian Brabandt <cb@256bit.org>
