Potential fix for code scanning alert no. 2: Uncontrolled command line

[sys-vdms]

Potential fix for https://github.com/IntelLabs/Video-Curation-Sample/security/code-scanning/2

General approach: keep using shell=False and a fixed executable path, but further reduce the attack surface by (a) enforcing a strict allowlist of characters/format for video names, and (b) ensuring we don’t accidentally proceed when ffprobe fails. This aligns with the recommendation to choose among hard-coded command structures and strictly validate any user-controlled arguments.

Concretely, the best targeted fix with minimal functional change is:

1. Strengthen validate_video_name in video/utils.py to only accept benign file-name patterns (e.g., letters, digits, underscore, dash, dot), while still rejecting path separators. This makes it explicit that video is not an arbitrary string but a constrained identifier/filename, which addresses CodeQL’s concern about uncontrolled values in a command line.
2. Improve _get_info in video/info.py to:
   • Use the already-safe path construction, but store it in a local variable for clarity.
   • Check the return code of ffprobe and raise an exception if it fails, instead of silently returning zeros. That way, invalid or malicious inputs don’t just flow through.
   • Avoid unnecessary manual p.stdout.close()/p.wait() by using communicate() or, minimally, by checking p.returncode after wait().

We do not need to change imports beyond adding re in video/utils.py for pattern-based validation. No changes to existing behavior for valid names are intended; valid names that match the new pattern should behave the same.

Specific changes:

• In video/utils.py, add import re and update validate_video_name to use a compiled regex like ^[A-Za-z0-9._-]+$ and to disallow names starting with a dot (to avoid hidden files like .htaccess if that matters).
• In video/info.py, inside _get_info, assign input_path = safely_join_path(self._mp4path, video) and use that in cmd. After the with Popen(...) block completes, check p.returncode and, if non-zero, raise a RuntimeError so the caller can fail cleanly. This makes error handling explicit and ensures we don’t treat a failed subprocess as a successful info query.

---

Suggested fixes powered by Copilot Autofix. Review carefully before merging.