- Move whitespace formatting settings from the indent to the filetype
plugin behind a "typst_recommended_style" config option.
- Set browsefilter
- Improve syntax file
Thanks to Maxim Kim for taking on maintainership of the typst runtime
files.
related: vim/vim#20036
closes: vim/vim#20077dd8975428b
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Co-authored-by: Maxim Kim <habamax@gmail.com>
Problem: [security]: With C omni-completion, a crafted tags file can execute
arbitrary Ex commands when completing a struct/union member
(cipher-creator)
Solution: Escape the type field before inserting it into the :vimgrep
pattern so it cannot close the pattern and start a new command
(Hirohito Higashi).
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-mf92-v4xw-j45x6b611b0d15
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem: [security]: potential powershell code execution in zip.vim
(DDugs)
Solution: Cleanup zip.vim, introduce PSEscape() to escape() potential powershell code,
use consistent s:Escape() in the various PowerShell functions
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-x5fg-h5w9-9frfb2cc9be119
Co-authored-by: Christian Brabandt <cb@256bit.org>
Patch 9.2.0306 fixed malformed lz4 extraction commands by using "tar -I lz4"
on Linux and leaving non-Linux tar implementations to auto-detect lz4 input.
That still fails on systems where tar does not support either -I lz4 or
automatic lz4 decompression, such as Solaris /usr/bin/tar.
Keep the existing Linux path using GNU tar's "-I lz4" support. For non-Linux
systems, use lz4 explicitly to decompress the archive to stdout and feed the
resulting tar stream to the configured tar extraction command. This is the
same style tar.vim already used for lz4 archives before patch 9.2.0306.
Follow-up for vim/vim#19925closes: vim/vim#20555b0ce576fbc
Co-authored-by: Vladimír Marek <vlmarek13@gmail.com>
Problem: [security]: another possible code execution with python complete
(David Carliez)
Solution: Strip default expressions and annotations from generated
source for pythoncomplete and python3complete.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-65p9-mwwx-7468c8c63673bc
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: The security patch 9.2.0561 added a vim.eval() call inside
Completer.evalsource() to honor g:pythoncomplete_allow_import.
But the 'vim' module is only imported inside the outer
vimcomplete() / vimpy3complete() function, not at the script's
top level, so referring to it from a Completer method raises
NameError. The surrounding bare 'except' silently swallows
the error and leaves allow_imports at 0, meaning the opt-in
never takes effect -- 'import os' (and any other
buffer-level import) is always skipped, no candidates are
produced for 'os.<...>' and
Test_popup_and_preview_autocommand() fails on the Windows
CI matrix (Linux skips the test because Python 2 is absent).
Solution: Re-import 'vim' at the top of evalsource() in both
pythoncomplete.vim and python3complete.vim so the eval reads
the global, and set g:pythoncomplete_allow_import = 1 in the
test (it is the opt-in intended for callers that trust the
buffer contents) (thinca).
closes: vim/vim#20386868ad62cb8
Co-authored-by: thinca <thinca@gmail.com>
Problem: tests: no test for using shellescape() in combination with :!
Solution: Add a test that checks runtime files for using wrong
combination of shellescape() with ! ex command
This has lead to a few security relevant issues, so add a test that
checks all runtime files for any ! followed by a shellescape() that does
not use the {special} arg.
related: Commit: 3fb5e58fbc63d86a3e65f1a141b0d67af2 (patch 9.2.0479:
[security]: runtime(tar): command injection in tar plugin)
closes: vim/vim#20286
Supported by AI
fccc2adc98
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: shellescape() called without {special} flag for :! ex command
Solution: Pass 1 as second argument to shellescape() in :! contexts
related: Commit: 3fb5e58fbc63d86a3e65f1a141b0d67af2 (patch 9.2.0479:
[security]: runtime(tar): command injection in tar plugin)
129486193c
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Expected text for interactive marks is in a separate json file
from the tutor file. When the tutor file is updated, line numbers
(potentially many) have to be updated in the json file. This is a
burden for maintenance and automatic testing.
Solution: Put the expected text inline in the tutor file, marked
with `[[]]`. Parse and remove the comments before opening the tutor
file so extmarks can be applied.
Problem: runtime(tar): missing path traversal checks in tar#Extract()
Solution: Add check for leading slash, however gnu tar should already
detect this (q1uf3ng)
tar#Extract() did not check for ../ sequences or absolute paths,
unlike zip#Extract() which was patched in recent commits. Add the
same checks: ../ (relative traversal), leading slash (Unix), drive
letter and UNC/leading slash (Windows).
closes: vim/vim#19981490b737f3e
Co-authored-by: q1uf3ng <q1uf3ng@protone.me>
zip#Write(): the Windows path check did not match a single leading
slash (/path), which resolves to the current drive root on Windows.
Simplify the regex to match any leading slash or backslash.
zip#Extract(): add absolute path checks for both Unix and Windows,
matching the existing checks in zip#Write().
closes: vim/vim#19976351a16c88f
Co-authored-by: q1uf3ng <q1uf3ng@protone.me>
Problem:
Neovim's Node.js provider does not support the Bun package manager.
PR #26829 attempted to add this but used a hardcoded path and was abandoned.
Solution:
- Use `bun pm bin -g` to dynamically locate the global binary directory.
- Update `health.lua` to recognize bun installations.
Problem: runtime(tar): but with dotted path
Solution: Do not strip everything after the first dot
(Aaron Burrow)
tar#Extract was getting the extensionless basename by
stripping away everything starting with the leftmost
dot. So if a directory had a dot or the file had an
'extra' dot then the code did the wrong thing. For
example, if it was given:
/tmp/foo.bar/baz.tar.gz
Then it would treat /tmp/foo as the extensionless
basename, but it actually should have grabbed:
/tmp/foo.bar/baz
This patch fixes the issue by instead looking at the
rightmost dot(s).
This bug was discovered by ChatGPT 5.4. I wrote the
patch and tested vim.
closes: vim/vim#199304a1bcc67b4
Co-authored-by: Aaron Burrow <burrows@fastmail.com>
Problem: patch 9.2.0325: runtime(tar): bug in zstd handling
Solution: use correct --zstd argument, separated from other arguments,
rework testing framework (Aaron Burrow).
The tar.vim plugin allows vim to read and manipulate zstd archives,
but it had a bug that caused extraction attempts to fail.
Specifically, if the archive has a .tar.zst or .tzst extension, then
the code was generating invalid extraction commands that looked like
this:
tar --zstdpxf foo.tar.zst foo
When they should be like this:
tar --zstd -pxf foo.tar.zst foo
This patch changes the flag manipulation logic so that --zstd isn't
glued to pxf.
The labor for this change was divided between ChatGPT 5.4 and me.
ChatGPT 5.4 identified the issue (from a code scan?), and I wrote
the patch and tested vim.
related: vim/vim#1993000285c035a
Note: tests need the next patch to pass in Nvim.
Co-authored-by: Aaron Burrow <burrows@fastmail.com>
Problem: runtime(tar): some issues with lz4 support
Solution: Fix bugs (see below) (Aaron Burrow)
The tar plugin allows users to extract files from tar archives that are
compressed with lz4. But, tar#Extract() builds malformed extraction commands
for lz4-compressed tar archives. This commit fixes three issues in that code.
The first affects archives with a .tlz4 extension and the other two affect
archives with .tar.lz4 extension (but one of these is symmetric to the issue
that .tlz4 archives had).
(1) When trying to extract .tlz4 archives the command created by
tar#Extract looked like this:
tar -I lz4pxf foo.tlz4 foo
This isn't right. It should be something like this:
tar -I lz4 -pxf foo.tlz4 foo
This was happening because tar.plugin is just substituting on the
first - in "tar -pxf". This works fine if we just add a simple flag for
extraction (eg, z for .tgz), but for lz4 we need to add "-I lz4".
I don't believe that there is an obvious good way to fix this without
reworking the way the command is generated. Probably we should collect
the command and flags separately and the flags should be stored in a
set. Then put everything together into a string just before issuing it
as an extraction command. Unfortunately, this might break things for users
because they have access to tar_extractcmd.
This patch just makes the substitution a little bit more clever so that it
does the right thing when substituting on a string like "tar -pxf".
(2) .tar.lz4 extractions had the same issue, which my patch fixes in
the same way.
(3) .tar.lz4 extractions had another issue. There was a space missing
in the command generated by tar#Extract. This meant that commands
looked like this (notice the lack of space between the archive and output
file names):
tar -I lz4pxf foo.tar.lz4foo
This patch just puts a space where it should be.
Finally, I should note that ChatGPT 5.4 initially identified this issue
in the code and generated the test cases. I reviewed the test cases,
wrote the patch, and actually ran vim against the tests (both with and
without the patch).
closes: vim/vim#1992578954f86c2
Co-authored-by: Aaron Burrow <burrows@fastmail.com>
Problem: runtime(zip): may write using absolute paths
(syndicate)
Solution: Detect this case and abort on Unix, warn in the documentation
about possible issues
46f530e517
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
`:Tutor` should open a copy of the tutor file instead of the original. This is
because edits modify the original file buffer, and crashes or other misuse could
potentially corrupt the original file even if it's WO.
Solution:
Copy the tutor file to a temp path before opening. Store the original path in
`b:tutor_file` so metadata json loading still works.
- `tutor#TutorCmd` will now copy the tutor file to a temp path via `tempname()`
before opening with `drop`. Store the original path in `b:tutor_file` only
after the buffer is created.
- `tutor#LoadMetadata` now uses `b:tutor_file` to resolve the JSON path instead
of `expand('%')`, which now points to the temp copy buffer
- `ftplugin/tutor.vim` does not make the `tutor#LoadMetadata` call anymore. It
was guarded by `filereadable(expand('%').'.json')` which fails for the new
temp copy path logic . Instead, `tutor#LoadMetadata` is already called
directly inside `tutor#TutorCmd` since we are already assumed to enable
interactive.
Co-authored-by: Phạm Bình An <111893501+brianhuster@users.noreply.github.com>
- ':!' is not stable, so use system() to get more consistent behaviour.
- Only warns when using 'pwsh'.
- Remove trailing spaces.
closes: vim/vim#19370abac1c1aa6
Co-authored-by: Mao-Yining <mao.yining@outlook.com>
Co-Authored-by: @lxhillwind
Problem: search() is used to check for the message from tar that
indicates leading slashes found in the tar archive, or to
check for the leading slashes themselves. However, if
'nowrapscan' is in effect these searches are limited to the
last line and don't find any results. This causes the warning
message from tar to be seen in the buffer, the "Path Traversal
Attack Detected" message to be omitted, and editing actions
can fail. This can be seen, for example, when editing
src/testdir/samples/evil.tar.
Solution: Use the 'w' flag for search() (Kevin Goodsell)
closes: vim/vim#1933318d844e365
Co-authored-by: Kevin Goodsell <kevin-opensource@omegacrash.net>
This reverts commits:
- 6b652a785033fd4164e049492a7327c1ed7c3e5f
- 2f689d5abde0ccddca9e20d8c93a0299bd054e32
- a025a46d4169587145fb54f04af349cd05cb6122
Several email addresses that are known to be valid caused bounces
due to an issue with my email setup. The previous commits incorrectly
marked these addresses as invalid. So revert the whole thing again.
62d8f3dab5
N/A patch:
vim-patch:2f689d5: runtime: mark more invalid email addresses
Co-authored-by: Christian Brabandt <cb@256bit.org>
This reverts 2495e7e. That past change meant that we would modify the
buffer contents of a tmux session if it exists, even if the current Nvim
process wasn't running inside of it. Depending on the tmux
configuration, this could even affect the clipboard of an actually
attached tmux client, since tmux itself uses OSC 52 to forward buffer
writes to attached clients.
While autodetection is usually a trade-off and can rarely make everybody
happy, this behavior goes counter the principle of least surprise. If
really desired, it can be brought back by explicit configuration.
Problem:
Spell file downloads relied on Vimscript and netrw (:Nread). If netrw is
disabled, downloads fail.
Solution:
Port the logic to Lua as `nvim.spellfile` and wire it via a Lua plugin that
handles `SpellFileMissing`. Use `vim.net.request()` with a timeout for HTTP,
prompt via `vim.fn.input` and report via `vim.notify`.
Closes#7189
