Giters

vim / vim-appimage

AppImage for gVim

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

included libraries; recent xz-utils / liblzma compromise

mralusw opened this issue · comments

commented

I ran

$ GVim-v9.1.0228.glibc2.29-x86_64.AppImage &
$ ls -d /tmp/.mount*  # get auto-mounted AppDir
# /tmp/.mount_GVim-vRwbSEr

$ ldd /tmp/.mount_GVim-vRwbSEr/usr/bin/vim | grep -E 'lzma|systemd|perl|ruby|python|lua'
	liblua5.3.so.0 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/liblua5.3.so.0 (0x00007efc1b9f4000)
	libperl.so.5.30 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libperl.so.5.30 (0x00007efc1b600000)
	libpython2.7.so.1.0 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libpython2.7.so.1.0 (0x00007efc1b200000)
	libruby-2.7.so.2.7 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libruby-2.7.so.2.7 (0x00007efc1ac00000)
	libsystemd.so.0 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/libsystemd.so.0 (0x00007efc19cc2000)
	liblzma.so.5 => /tmp/.mount_GVim-vRwbSEr/usr/bin/../lib/liblzma.so.5 (0x00007efc19c74000)

Two things to note here:

  • The appimages do include libruby, llibperl, liblua and (interestingly) libpython2 (but not 3) which is different from what the release notes / documentation state. I had some release note PR's coming up in any case for unrelated stuff (AppRun.extracted), so I ended up verifying and rewriting the docs.
  • by now I suppose everyone has heard of the xz / liblzma5 / sshd backdoor (e.g. see the Debian fallout).
    • in short, Debian stable doesn't seem to be affected, and the vulnerability only seems to target Debian/Redhat-patched sshd anyway
    • because the vim-appimage's are currently built with Ubuntu 20.04, we probably link to (and "ship") even older versions. I think vim can access compression algorithms (e.g. via its embedded languages) so this might still be a relevant point
    • the appimage compression algorithm (for the embedded squashfs) is gzip, not xz (see below)
$ GVim-v9.1.0228.glibc2.29-x86_64.AppImage --appimage-offset
193728
$ dd if=GVim-v9.1.0228.glibc2.29-x86_64.AppImage of=/tmp/x.squashfs bs=193728 skip=1
# ...
$ file /tmp/x.squashfs
/tmp/x.squashfs: Squashfs filesystem, little endian, version 4.0, zlib compressed  # ...
commented

yes, so we should not be affected. So anything to do for us here?

commented

On the compromise, no, we should be more than OK (but I thought I'd check).

I'm trying to figure out what's going on with the embedded languages. We clearly ship some libraries as ldd shows (and unlike what the release notes state).

  • Python 3 apparently does not run out of the box (:python3 yields E319).
  • Python 2 also does not work (E887) but it seems like it might be fixable by using the target's runtime (?)
  • Lua seems to work and fixed at 5.3
  • Perl at 5.30

I think the release notes are also wrong about installing those interpreters on the system — if they work at all, they will work with the builtin appimage version.

commented

Findings: all interpreters are currently configured with --enable-*interp. This means right now:

  • all interpreters are "available" regardless of what's installed on the user's system
  • but unless the user has Ubuntu 20.04, no interpreter will find their default packages
  • in particular, Python 2 is enabled, but it can't actually run anything useful
  • the others work to varying degrees (e.g. Lua doesn't seem to need anything)

I've reconfigured my builds to include this in scripts/build_vim.sh

CFG_OPTS+=( "--disable-pythoninterp" )
CFG_OPTS+=( "--enable-python3interp=dynamic" )
CFG_OPTS+=( "--with-python3-stable-abi=3.8" )

Only Python3 seems to have stable-ABI capabilities. On any system, one can set pythonthreedll=libpython3.11.so or whatever, and appimage-vim will use it. To simplify things, I've written a vim script to auto-search for an the appropriate "dll" (link below); it seems to work on at least Debian derivatives.

For the other interpreters , vimhelp says this about */dyn configurations:

The version of the shared library must match the $INTERP version Vim was compiled with.

… so for those, maybe non-dynamic is the least bad option.

What do you think should be done? I could

  • turn on dynamic python3 and disable python2 with the CFG ops above
  • document the real state of affairs
  • add a PR for search-interpreter-dlls.vim to the main branch, and
    • (maybe?) add it to the appimage-vim's default startup sequence, though this seems too much