Hi James,

while working on the fix for CVE-2026-52859 for trixie I noticed that the
test that patch adds also passes on an unfixed vim: the out-of-bounds
read lands in adjacent struct memory, so on a normal build the output is
unchanged. It only fails on an instrumented build (I verified the
unfixed read with valgrind; upstream's CI catches it in their ASAN+UBSAN
job, which is what these regression tests are really written for).

Skimming other security fixes, several of their tests have the same
property: they trigger the buggy code path but can only fail under a
sanitizer. On our plain builds they're effectively no-ops as regression
tests, both at build time and in autopkgtest.

My current thinking is an autopkgtest with @builddeps@ that builds vim
with -fsanitize=address,undefined from the packaged source and runs (a
subset of) the test suite against that binary. What's your opinion?

Greets,
Lee
--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

While that would work, that's kind of counter to the purpose of
autopkgtests, as I understand it. They're supposed to be testing the
installed binaries.

If using valgrind would work, that seems a bit better, but it's not
clear to me that it's really worth the effort.

Cheers,