Files
bambuddy/requirements.txt
T
maziggy f15e54c383 fix(windows): _local_zone falls back to stdlib utc when zoneinfo DB is missing
The Windows installer's embedded Python doesn't carry an IANA tz
  database, and the stdlib zoneinfo has no system DB to read on Windows.
  ZoneInfo("UTC") raises ZoneInfoNotFoundError on those installs, and
  the new /api/local-backup/status endpoint 500s on the resulting
  uncaught exception. Surfaced via a Windows traceback from a user's log:

    File "...\backend\app\services\local_backup.py", line 32, in _local_zone
      return ZoneInfo("UTC")
    zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'

  _local_zone()'s try/except only covered the TZ-env branch — both
  fallbacks unconditionally called ZoneInfo("UTC") and re-raised.

  Fix (two parts):

  1. services/local_backup.py — return type widened from ZoneInfo to
     tzinfo, the UTC fallback is wrapped in its own try, and the
     last-resort fallback returns datetime.timezone.utc (stdlib, no
     IANA DB needed). str(timezone.utc) == "UTC" so the response shape
     on /api/local-backup/status is unchanged. The astimezone call in
     _calculate_next_run accepts any tzinfo — no other call sites
     affected.

  2. requirements.txt — pin tzdata>=2024.1; sys_platform == "win32" so
     the next Windows installer build ships the IANA DB, and any non-
     UTC TZ value (e.g. Europe/Berlin) resolves correctly. The stdlib
     fallback can only ever give UTC. Linux/macOS unaffected by the
     platform marker — they already have the system tz database.
2026-06-13 07:49:31 +02:00

131 lines
4.4 KiB
Plaintext

# Web Framework
# fastapi 0.136.x ships an undocumented `fastar` dep in its [standard]
# extras group (MAL-2026-4750, surfaced by Amazon Inspector). `fastar`
# is a Rust-tar binding package — no plausible reason for a web
# framework to depend on it. Even if `fastar` is benign today, the
# advisory's framing as a namespace-abuse / supply-chain vector is
# valid: anyone controlling the `fastar` PyPI namespace gains code
# execution at install time across every fastapi[standard] install.
# Bambuddy doesn't request [standard], so we don't pull `fastar` in
# practice, but pip-audit flags the package itself and breaks CI.
# Hold to 0.135.x (which has all features we use, including SSE)
# until upstream removes the dep or explains the rationale.
fastapi>=0.109.0,<0.136.0
uvicorn[standard]>=0.27.0
# Database
sqlalchemy>=2.0.0
aiosqlite>=0.19.0
asyncpg>=0.29.0
greenlet>=3.0.0
# Pydantic
pydantic>=2.0.0
pydantic-settings>=2.0.0
# Transitive of pydantic-settings, floor-pinned to patch CVE-2026-28684 (dotenv 1.2.1)
python-dotenv>=1.2.2
# Bambu Lab Printer Communication
paho-mqtt>=2.0.0
aioftp>=0.22.0
# Virtual Printer (emulates Bambu printer for slicer uploads)
pyftpdlib>=2.0.0
cryptography>=46.0.7
# SpoolBuddy remote SSH updates (pure-Python SSH client; avoids the
# OpenSSH `ssh` binary which calls getpwuid() and fails in Docker when
# the container UID isn't in /etc/passwd)
asyncssh>=2.18.0
# 3MF Processing (standard zipfile is sufficient for Bambu 3MF files)
defusedxml>=0.7.0 # Safe XML parsing (prevents XXE attacks)
# Excel Export
openpyxl>=3.1.0
# Notifications
pywebpush>=2.0.0
# Utilities
python-multipart>=0.0.27
aiofiles>=23.0.0
# QR Code generation
qrcode[pil]>=7.4.0
# PDF generation (spool label printing — #809)
reportlab>=4.0.0
# STL Thumbnail Generation
trimesh>=4.0.0
matplotlib>=3.8.0
fast-simplification>=0.1.0
# System monitoring
psutil>=6.0.0
# IANA tz database for Windows. The stdlib ``zoneinfo`` module reads the
# system tz database on Linux/macOS, but Windows has none — and the
# embedded Python in our Windows installer doesn't carry one either, so
# even ``ZoneInfo("UTC")`` raises ``ZoneInfoNotFoundError`` and any
# endpoint that resolves a tz (e.g. /api/local-backup/status) 500s.
# ``tzdata`` is the official PyPI package that fills the gap.
tzdata>=2024.1; sys_platform == "win32"
# Authentication
PyJWT>=2.13.0
passlib[bcrypt]>=1.7.4
ldap3>=2.9.0
pyotp>=2.9.0
# Transitive dep pin: idna<3.15 has CVE-2026-45409 (ReDoS on encode() with
# crafted Unicode). Pulled in by anyio/httpx/requests/yarl; pin the floor
# so we don't regress when a downstream loosens its constraint.
idna>=3.15
# HTTP client (used for OIDC token exchange)
httpx>=0.26.0
# HTTP client with browser TLS-fingerprint impersonation. Used only for
# the bambulab.com firmware-download page in services/firmware_check.py:
# Bambu's Cloudflare WAF gates the page behind a JA3/TLS-fingerprint
# challenge that plain httpx/requests can't pass (#1666). curl_cffi
# replays Chrome's ClientHello bytes so the TLS handshake clears CF;
# the HTTP-layer User-Agent stays honest Bambuddy/1.0 per our compliance
# commitment. Soft dependency — if it fails to import (rare platforms,
# constrained installs), firmware_check degrades gracefully to wiki-only
# version detection and logs a warning at startup.
curl_cffi>=0.7.0
# Transitive pin: urllib3 2.6.3 has CVE-2026-44431 and CVE-2026-44432;
# 2.7.0+ is the fixed release. Direct pin here because none of our
# top-level deps require >=2.7.0 yet, so without this the resolver
# would silently keep installing the vulnerable 2.6.x line.
urllib3>=2.7.0
# Transitive of fastapi. starlette 1.0.0 has PYSEC-2026-161; 1.0.1 is the
# fixed release. fastapi's range still admits 1.0.0 so we pin the floor
# directly to stop the resolver from picking the vulnerable build.
starlette>=1.0.1
# Transitive of pywebpush (unpinned `aiohttp` requirement). aiohttp 3.13.5
# has CVE-2026-34993 and CVE-2026-47265, both fixed in 3.14.0. pywebpush
# doesn't declare an upper bound either way, so without this pin the
# resolver keeps installing the vulnerable 3.13.x line. Our direct usage
# in services/external_camera.py (ClientSession, ClientTimeout, ClientError,
# iter_chunked) is unaffected by 3.14.0.
aiohttp>=3.14.0
# Plate Detection (optional - enables build plate empty detection)
opencv-python-headless>=4.8.0
numpy>=1.24.0
# Development
pytest>=9.0.3
pytest-asyncio>=0.23.0
httpx>=0.26.0
ruff>=0.2.0
pillow>=12.2.0