cv2 import appends a trailing ":" to LD_LIBRARY_PATH — empty entry resolves to CWD and breaks child processes

最小限の再現手順を実行し、その後 cv2/init.py の 146-147 行付近にある POSIX 分岐を調べ、BINARIES_PATHS がどのように使用されているかを追跡します。cv2 のインポートによって空の LD_LIBRARY_PATH エントリが作成されなくなり、無関係な子プロセスが安全でないパスを継承することもなくなれば完了です。リポジトリに適切なテスト場所が用意されている場合は、回帰テストのカバレッジを追加してください。

Environment

• opencv-python: reproduced on 4.11.0.86, 4.12.0.88, 4.13.0.92, 4.14.0.94 and 5.0.0.93 (PyPI manylinux x86_64 wheels; earliest tested 4.11.0.86, Jan 2025)
• Python 3.13.15 / 3.14.7, Linux x86_64 (glibc; CachyOS/Arch, kernel 6.x)

Minimal reproduction

python -m venv venv && venv/bin/pip install opencv-python==5.0.0.93
venv/bin/python - <<'EOF'
import os, subprocess

print("before import:", repr(os.environ.get("LD_LIBRARY_PATH")))
import cv2
print("cv2", cv2.__version__, "after import:", repr(os.environ.get("LD_LIBRARY_PATH")))
print("child sees:", subprocess.run(["sh", "-c", "printf '%s' \"$LD_LIBRARY_PATH\""],
      capture_output=True, text=True).stdout)
EOF

Observed

before import: None
cv2 5.0.0 after import: '/…/site-packages/cv2/../../lib64:'
child sees: '/…/site-packages/cv2/../../lib64:'

cv2/__init__.py (POSIX branch, cv2/__init__.py:146-147 in current wheels):

# amending of LD_LIBRARY_PATH works for sub-processes only
os.environ['LD_LIBRARY_PATH'] = ':'.join(l_vars['BINARIES_PATHS']) + ':' + os.environ.get('LD_LIBRARY_PATH', '')

Three problems in one line:

1. Unconditional trailing : — when LD_LIBRARY_PATH was previously unset the
   variable is created with a dangling separator. Per ld.so(8) semantics an empty
   entry resolves to the current working directory of every child process.
2. Global environment mutation — the comment itself notes this "works for
   sub-processes only", yet the write persists in os.environ for the whole
   process lifetime, so every subprocess/os.system/webbrowser call made by
   the host application inherits the modified path. This is invisible side-channel
   state an importer cannot reasonably expect from import cv2.
3. The injected directory typically does not exist — with standard manylinux
   wheel layouts the bundled libraries live in opencv_python.libs/ (located via
   $ORIGIN RPATH), and <site-packages>/cv2/../../lib64 is absent in venv,
   project, and standalone-packaged layouts, so the write buys nothing while
   adding the hazard.

Real-world impact

We ship a Nuitka-standalone application whose launcher cds into the release
folder. With cv2 imported, LD_LIBRARY_PATH ends with : → the release folder
(the CWD) enters the child loader path → children that load system OpenSSL
(xdg-open → kde-open, i.e. "open a URL in the default browser") resolve the
bundled, older libssl.so.3/libcrypto.so.3 instead of the system ones and die
with:

kde-open: libssl.so.3: version `OPENSSL_3.2.0' not found (required by /usr/lib/libcurl.so.4)

Any application that imports cv2 and then spawns helper processes from a
directory containing same-named libraries is affected the same way.

Suggested fix

• Do not append a dangling separator; only write the variable when there is
  something to add and prepend/append with proper joining:

  paths = l_vars['BINARIES_PATHS']
  if paths:
      old = os.environ.get('LD_LIBRARY_PATH')
      os.environ['LD_LIBRARY_PATH'] = ':'.join(paths) + (':' + old if old else '')
  

• Longer term, prefer not mutating the global environment at all: the bundled
  libraries are already found through $ORIGIN RPATH; if an env-based fallback
  is really needed, consider documenting it and cleaning up after import, or
  exposing an opt-in.

Happy to send a PR to opencv-python/opencv-python (the loader __init__.py)
if you agree with the direction.