mirror of
https://github.com/affaan-m/ECC.git
synced 2026-09-20 16:47:59 +02:00
Juan Garibay
9cdc40e6d1
This branch taught the hook to run `.venv/bin/python`, and that is a binary the repository can supply. On main the Python arm only ever ran `pytest` from PATH -- the developer's own -- and on a machine without one it ran nothing at all, which is exactly the machine this branch was written for. So the exposure is new, and it arrived with the fix. The hook is installed globally through core.hooksPath. Cloning a hostile repository, committing nothing, and pushing it to your own fork is enough: the pre-push hook finds the committed `.venv/bin/python`, runs it once to probe for pytest and again to run the suite. Reproduced -- the planted executable logged two invocations under the previous commit and none under this one. A virtualenv is never committed. It is platform-specific binaries and every Python project gitignores it, so `git ls-files --error-unmatch` separates the two cases exactly: a developer's own venv is untracked and still resolves, a tracked one is skipped with the reason printed. An absolute $VIRTUAL_ENV outside the worktree reads as untracked, as it should. Not addressed here, and worth a maintainer's view: `uv run` and `poetry run` resolve from the repository's own lockfile, so they carry the same shape of trust in a form this check cannot see. They are gated behind a lockfile being present, and changing their semantics is a larger decision than this fix.