mirror of
https://github.com/BerriAI/litellm.git
synced 2026-10-02 02:11:58 +00:00
f39c811d34
* fix(packaging): keep wheel paths under Windows MAX_PATH for Store Python pip install litellm fails on Microsoft Store Python because its user site-packages is already 134 chars plus the profile name, and the content filter guardrail ships YAML five directories deep under litellm/proxy/guardrails/guardrail_hooks/litellm_content_filter/. The existing wheel guard assumed a 100-char install prefix, so it never saw it. Move categories/ and policy_templates/ to litellm/proxy/guardrails/content_filter_data/ and drop the benchmark fixtures from the wheel. Old category_file paths keep resolving because the resolver only keys on the trailing categories/<file> or policy_templates/<file> suffix. Derive the guard's worst-case prefix from the Store Python site-packages path with a 15-char profile name (149), fail files at 260 and directories at 248 (CreateDirectoryW), and fix the off-by-one that let a 260-char path through. Fixes #43851 * ci: run the Windows wheel install guard on pull requests The two Windows jobs live in CircleCI, which never runs on pull requests, so nothing installs the wheel on Windows before merge. Add a GitHub Actions job on windows-latest that builds the wheel and runs the guard. Two things make the run deterministic instead of image dependent. The job turns the LongPathsEnabled registry key off first, because runner images ship with it on and python.exe is long-path aware, so a 300-char path would install fine. The guard installs with pip instead of uv, because uv writes files from Rust, which switches to extended-length paths on its own and can never hit MAX_PATH. * fix(guardrails): keep the old content filter package dir as a category search root Deployments that copied their own category YAML into guardrail_hooks/litellm_content_filter/ before the data move would have had that file rejected by the new directory jail and missing from by-name loads, inherit_from lookups, the UI category listing and the category YAML endpoint. Every lookup now searches the bundled data dir first and the old package dir second, with the bundled copy winning on a name clash. * fix(guardrails): resolve category files through safe_join By-name category lookups and the suffix search in the category_file resolver now go through safe_join, so a name or suffix that would escape its data root never reaches the filesystem. The LITELLM_CONTENT_FILTER_ALLOW_EXTERNAL_PATHS opt-out keeps its unjailed search. Clears the two CodeQL path-injection findings on the new lookup code. * fix(guardrails): keep symlinked category files loadable by name By-name category lookups resolved symlinks through safe_join, so a category file symlinked into the categories folder from elsewhere stopped loading. Those lookups now only reject names that leave the folder lexically and return the link untouched, matching how by-name loads behaved before the data move. The category_file resolver keeps its realpath jail as before. * fix(guardrails): keep the category viewer inside the category folders GET /guardrails/ui/category_yaml/{name} hands raw file contents to any valid key, and on main it refused a symlink whose target left the categories folder. The previous commit let by-name lookups follow symlinks again, which also let the viewer read whatever a symlink in a legacy categories folder pointed at. The viewer now checks the found file's real path against every categories folder it searches and answers 400 as before, while the guardrail's own by-name loads keep following symlinks The roots come in through a FastAPI dependency so the check is testable against a temp folder, and the content filter's realpath containment moves to path_utils.is_within so both surfaces share it. The test that patched os.path.commonpath covered a branch that no longer exists and goes with it * ci: drop the Windows wheel install job from pull requests The job took about 13 minutes on every PR to guard an edge case. The guard still runs its path-length check on Linux in base_sdk_install and on Windows in the CircleCI windows_release_wheel job. |
||
|---|---|---|
| .. | ||
| check_windows_wheel_install.py | ||
| test_check_windows_wheel_install.py | ||
| test_litellm_on_windows.py | ||