editors/vim9.2.1178

editors/vim: Update to 9.2.1178

editors/vim: Update to 9.2.0738

editors/vim: Update to 9.2.0611

editors/vim: Update to 9.2.0461

editors/vim: Update to 9.2.0387

editors/vim: Update to 9.2.0277

Addresses GHSA-8h6p-m6gr-mpw9 (see below).

editors/vim: Update to 9.2.0272 (security)

This update addresses GHSA-2gmj-rpqf-pxvh (see advisory link below):

Summary (from advisory):
  A bug chain in Vim allows arbitrary OS command execution when a user
  opens a crafted file. The tabpanel option is missing the P_MLE flag,
  allowing a modeline to inject a %{expr} expression string without
  requiring modelineexpr to be enabled. Although Vim correctly
  evaluates the expression inside the sandbox, autocmd_add() lacks
  a check_secure() call, allowing sandboxed code to register an
  autocommand that fires after the sandbox exits.

Security:	https://github.com/vim/vim/security/advisories/GHSA-2gmj-rpqf-pxvh

editors/vim: Update to 9.2.0204 (security fix)

In particular, this addresses the following:
  Problem:  The glob() function on Unix-like systems does not escape
            newline characters when expanding wildcards. A maliciously
            crafted string containing '\n' can be used as a command
            separator to execute arbitrary shell commands via
            mch_expand_wildcards(). This depends on the user's 'shell'
            setting.
  Solution: Add the newline character ('\n') to the SHELL_SPECIAL
            definition to ensure it is properly escaped before being
            passed to the shell (pyllyukko).

Security:	GHSA-w5jw-f54h-x46c

editors/vim: Update to 9.2.0140

Contains a fix for a null pointer dereferencing vulnerability in the
regex engine. Vim assigned it a MODERATE risk score. See the below
disclosure report.

Security:	https://github.com/vim/vim/security/advisories/GHSA-9phh-423r-778r

editors/vim: Update to 9.2.0073, multiple security fixes

While the minor has bumped, and much has changed from 9.1 to 9.2,
we've been incrementally adopting the patches so it's not "new" to us,
per se. All the gory details are at:
  https://github.com/vim/vim/blob/master/runtime/doc/version9.txt

This commit adds patches for six security issues:

patch 9.2.0073: [security]: possible command injection using netrw
Problem:  [security]: Insufficient validation of hostname and port in
          netrw URIs allows command injection via shell metacharacters
          (ehdgks0627, un3xploitable).
Solution: Implement stricter RFC1123 hostname and IP validation.
          Use shellescape() for the provided hostname and port.

Github Advisory:
GHSA-m3xh-9434-g336

patch 9.2.0074: [security]: Crash with overlong emacs tag file
Problem:  Crash with overlong emacs tag file, because of an OOB buffer
          read (ehdgks0627, un3xploitable)
Solution: Check for end of buffer and return early.

Github Advisory:
GHSA-h4mf-vg97-hj8j

patch 9.2.0075: [security]: Buffer underflow with emacs tag file
Problem:  When parsing a malformed Emacs-style tags file, a 1-byte
          heap-buffer-underflow read occurs if the 0x7f delimiter
          appears at the very beginning of a line. This happens
          because the code attempts to scan backward for a tag
          name from the delimiter without checking if space exists.
          (ehdgks0627, un3xploitable)
Solution: Add a check to ensure the delimiter (p_7f) is not at the
          start of the buffer (lbuf) before attempting to isolate
          the tag name.

GitHub Advisory:
GHSA-xcc8-r6c5-hvwv

patch 9.2.0076: [security]: buffer-overflow in terminal handling
Problem:  When processing terminal output with many combining characters
          from supplementary planes (4-byte UTF-8), a heap-buffer
          overflow occurs. Additionally, the loop iterating over
          cell characters can read past the end of the vterm array
          (ehdgks0627, un3xploitable).
Solution: Use VTERM_MAX_CHARS_PER_CELL * 4 for ga_grow() to ensure
          sufficient space. Add a boundary check to the character
          loop to prevent index out-of-bounds access.

Github Advisory:
GHSA-rvj2-jrf9-2phg

patch 9.2.0077: [security]: Crash when recovering a corrupted swap file
Problem:  memline: a crafted swap files with bogus pe_page_count/pe_bnum
          values could cause a multi-GB allocation via mf_get(), and
          invalid pe_old_lnum/pe_line_count values could cause a SEGV
          when passed to readfile() (ehdgks0627, un3xploitable)
Solution: Add bounds checks on pe_page_count and pe_bnum against
          mf_blocknr_max before descending into the block tree, and
          validate pe_old_lnum >= 1 and pe_line_count > 0 before calling
          readfile().

Github Advisory:
GHSA-r2gw-2x48-jj5p

patch 9.2.0078: [security]: stack-buffer-overflow in build_stl_str_hl()
Problem:  A stack-buffer-overflow occurs when rendering a statusline
          with a multi-byte fill character on a very wide terminal.
          The size check in build_stl_str_hl() uses the cell width
          rather than the byte length, allowing the subsequent fill
          loop to write beyond the 4096-byte MAXPATHL buffer
          (ehdgks0627, un3xploitable).
Solution: Update the size check to account for the byte length of
          the fill character (using MB_CHAR2LEN).

Github Advisory:
GHSA-gmqx-prf2-8mwf

Security:	Multiple (see commit message)

editors/vim: Update to 9.1.2148

Security:	https://github.com/vim/vim/security/advisories/GHSA-9w5c-hwr9-hc68

editors/vim: Update to 9.1.2144

editors/vim: Update to 9.1.2125

editors/vim: Update to 9.1.2050

editors/vim: Update to 9.1.1948

Security: Arbitrary code execution (as user running vim). HIGH severity.
          https://github.com/vim/vim/security/advisories/GHSA-g77q-xrww-p834

editors/vim: Update to 9.1.1942

editors/vim: Update to 9.1.1840

editors/vim: Update to 9.1.1744 and handle wayland properly

Add --without-wayland for everything except the gtk3 FLAVOR. That
flavor now has a hard dep on wayland (it's already present from the
default gtk30 and libxkbcommon configurations).

This is a NOOP for everybody except gtk3 users who explicitly disabled
wayland in both gtk30 and libxkbcommon. The only effect for those
users is that wayland is now a LIB_DEP. There is no runtime effect
either way.

In the below PR, Piotr identified that vim will eagerly link against
wayland if present, even for a pure-console build.

The only toolkit that vim uses that can use wayland is gtk3, so
we now specify --without-wayland for everything else.

To complicate things, wayland support is optional in the gtk30 and
libxkbcommon ports. If either of those ports are built with wayland,
then vim has to link against libwayland-client regardless of the
relevant configure switches. So, adding a WAYLAND option for the gtk3
flavor would only work to disable wayland if it's disabled in both
gtk30 and libxkbcommon.

Instead, I'm making wayland a hard dep of the gtk3 flavor. For users
of our packages, this will be a transparent change. If your goal in
life is to never install wayland but you also want the gtk3 flavor,

PR:             289408
Reported by:    Piotr Smyrak

editors/vim: Don't clobber USES

editors/vim: Update to 9.1.1723

This update changes how python plugins are handled. Previosuly, we
linked directly against python, requiring all vim installations to
have a dependency on python. Perhaps that's fine for flavours like
gtk20 and gtk30, but it's burdensome and often unexpected for TUI
users.

Now, we use dynamic loading of python libraries, which means that
vim should automatically support python plugins if python is
installed. If python is NOT installed, no harm/no foul, just no
python plugin support.

I'm not expecting this to cause any issues, but if it does please
reach out!

editors/vim: Update to 9.1.1627

editors/vim: Bump PORTREVISION for previous commit

PR:		288515

editors/vim: Pull in gnome.mk's gdkpixhufextra to fix runtime warnings

Non-fatal console warnings were generated when running vim-gtk3 and 2.
This is due to certain loadable modules moving from gdk-pixhuf to
gdk-pixbuf-extras.

See https://forums.freebsd.org/threads/gvim-messages-gdkpixbuf-warning-and-glib-gobject-critical.98679/
PR:		Yusuf Yaman
Reported by:	thierry, in the above FreeBSD Forums post
MFH:		2025Q3

editors/vim: Update to 9.1.1563

CWE for both CVEs:

  Improper Limitation of a Pathname to a Restricted Directory ('Path
  Traversal') (CWE-22)

Security:	CVE-2025-53905
Security:	CVE-2025-53906

editors/vim: Update to 9.1.1401

editors/vim: Update to 9.1.1378

editors/vim: Update to 9.1.1362

editors/vim: Update to 9.1.1265

gnome.mk: rename gdkpixbuf2 to gdkpixbuf to prepare for port move

The GTK 1-based gdk-pixbuf has not existed for some time.

No functional or package changes.

editors/vim: Update to 9.1.1198 (security)

potential data loss with zip.vim and special crafted zip files

Date: 12.03.2025
Severity: Medium
CVE: CVE-2025-29768
CWE: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') (CWE-88)
Summary

potential data loss with zip.vim and special crafted zip files
Description

Vim is distributed with the zip.vim plugin, that allows easy editing and
viewing of zip archives.

To view and extract zip files, vim uses the unzip(1) command, usually
provided by Info-ZIP, latest version on Debian is 6.0 from April 2009.

If an attacker creates an archive which contains a file -d/tmp, and a Vim
user views such a file and tries to extract such filename from
the archive, Vim will essentially run the following unzip command:

unzip -o <archive.zip> member-filename

However, since the member-filename is called -d/tmp, this is seen by
the unzip command as an additional argument and it therefore happily
extracts the whole archive into the mentioned directory, overwriting existing
files because of the -o.

Unfortunately, the latest released unzip version does not support --
as and end-of-argument marker, so we cannot use this to mark the
beginning of the member-files for unzip. Well, apparently there exists
some 6.10 beta release, that hasn't made it to an official release
yet which supports the use of the -- marker since 2010 (but this isn't
widely known).

Therefore, Vim will try to work-around it by using the [-] glob when a
filename starts with a - to protect unzip from parsing the filename as
an argument, which is just an ugly work-around.
Impact

Impact is moderate because a user must be made to view such an archive
with Vim and then press 'x' to extract such a strange filename.

The Vim project would like to thank @Ry0taK (GMO Flatt Security Inc) and
@takumi-san-ai for reporting this issue.

MFH:		2025Q1
Security:	GHSA-693p-m996-3rmf

editors/vim: Update to 9.1.1164 (security, high severity)

From the Github Advisory (https://github.com/vim/vim/security/advisories/GHSA-wfmf-8626-q3r3):
  Summary:

      Potential code execution with tar.vim and special crafted tar
      files.

  Description:

      Vim is distributed with the tar.vim plugin, that allows easy
      editing and viewing of (compressed or uncompressed) tar files.

      Since commit 129a844 (Nov 11, 2024 runtime(tar): Update tar.vim to
      support permissions), the tar.vim plugin uses the ":read " ex
      command line to append below the cursor position, however the is
      not sanitized and is taken literaly from the tar archive. This
      allows to execute shell commands via special crafted tar archives.
      Whether this really happens, depends on the shell being used
      ('shell' option, which is set using $SHELL).

  Impact:

      Impact is high but a user must be convinced to edit such a file
      using Vim which will reveal the filename, so a careful user may
      suspect some strange things going on.

  The Vim project would like to thank RyotaK (GMO Flatt Security Inc)
  for reporting this issue.

  The issue has been fixed as of Vim patch v9.1.1164.

MFH:		2025Q1
Security:	GHSA-wfmf-8626-q3r3

editors/vim: Update to 9.1.1117

editors/vim: Update to 9.1.1043

editors/vim: Update to 9.1.1006

editors/vim: Update to 9.1.0984

editors/vim: Update to 9.1.0915

editors/vim: Update to 9.1.0764

editors/vim: Update to 9.1.0708

editors/vim: Update to 9.1.0697

editors/vim: Update to 9.1.0689

editors/vim: Update to 9.1.0678

editors/vim: Update to 9.1.0652

editors/vim: Update to 9.1.0530

editors/vim: Update to 9.1.0470

editors/vim: Update to 9.1.0404

editors/vim: Update to 9.1.0158

While here:
- Add explicit --disable-libsodium [1]
- Clear PORTREVISION on xxd as it gets a bump from this update

PR:		277545
Reported by:	dewayne heuristicsystems com au [1]

editors/vim: Impelled to share/man

Approved by:    portmgr (blanket)

MAN?PREFIX: eleminate its usage  and move man to share/man

editors/vim: Update to 9.1.0015

*/*: Bump consumers of x11-toolkits/gtk30

New version of gtk3 in tree