Spaces:
Running
Running
Commit History
-
refactor(utils): add shared json_safe.sanitize()
Extracted from analyze.py's _sanitize(), which sse_analyzer.py had a second, near-duplicate (and already-drifted) copy of. Also fixes a real bug found while writing tests for this: a numpy NaN/Infinity scalar was converted to a native float but never actually checked for being non-finite, because the numpy-conversion branch returned early. Both duplicates had this bug; fixed here rather than carried forward.91db04e
-
chore(comments): trim verbose BUG FIX comment in validators.py
Completes the Campaign E comment-cleanup pass across all 17 files that had accumulated multi-paragraph 'BUG FIX' narrative comments -- that history belongs in commit messages, not living in the source forever.65e2f34 -
fix(F-18): set MAX_IMAGE_PIXELS at import time, not first function call
Image.MAX_IMAGE_PIXELS = 50_000_000 used to run inside assess_image_quality(), which analyze.py imported and called locally INSIDE the request handler, AFTER the EXIF-orientation-correction block (Image.open() + exif_transpose() + .save() -- a full decode/re-encode, exactly the operation this limit exists to protect). So that earlier step ran under Pillow's default ~89-megapixel ceiling instead of this project's intended, tighter 50-megapixel one for every request before the first call to assess_image_quality() happened to occur. Moves the assignment to module level in image_quality.py (executes once at import) and changes analyze.py's import of assess_image_quality from a per-request local import to a top-of-file module import, so the limit is guaranteed to be in effect before the process ever handles a request, not just after the first one that happens to reach assess_image_quality(). Verified directly: importing backend.api.routes.analyze now changes PIL.Image.MAX_IMAGE_PIXELS fro…fcba924
-
refactor(logging): standardize all remaining files onto setup_logger()
18 files (17, once adversarial_tester.py — missed by the original audit's grep — is included) called bare logging.getLogger(__name__) instead of the project's own core/logger.py::setup_logger(). Since nothing in the running app calls logging.basicConfig(), those loggers defaulted to effective level WARNING with no handler of their own: .info()/.debug() calls were silently discarded, and .warning()/.error() calls surfaced unformatted via Python's 'last resort' handler instead of the intended stdout stream — meaning 17-18 modules' operational logs were effectively invisible. Fix: from backend.core.logger import setup_logger; logger = setup_logger(name), matching every other module in the codebase. Mechanical, behavior-neutral outside of logging output itself. Verified repo-wide after this commit: the only remaining logging.getLogger() call anywhere in backend/ is setup_logger()'s own internal implementation in core/logger.py, as expected.fcea3b7
-
fix(security): enforce extension_valid instead of silently discarding it
validate_file() computed extension_valid (extension-vs-MIME cross-check, specifically meant to catch spoofed/renamed files) and returned it in the result dict, but hardcoded 'valid': True regardless of its value. Separately, FileValidationResponse (the /api/v1/upload/ validate response model) never declared an extension_valid field at all — Pydantic v2's extra='ignore' default silently dropped it even if the caller had checked it. Net effect, confirmed: /api/v1/upload/validate always reported valid: true for any file with an allowed MIME type, no matter how suspicious the extension. This exact bug was already found and fixed in analyze.py's sibling endpoint (its own comment says 'previously silently discarded') — the fix never propagated to upload.py. Fix: validate_file() now raises FileValidationError when extension_valid is False; FileValidationResponse now declares the field explicitly so it's never silently dropped even in future call sites.99f78e6
-
fix: add PIL MAX_IMAGE_PIXELS=50M and explicit >10000px rejection (audit #6)
35363b1 -
fix: add extension_valid key to validate_file() — was always True (audit #1)
661db04
-
feat(quality): add image quality gate before forensic analysis
backend/utils/image_quality.py — assess_image_quality() checks images before expensive processing: - Rejects images < 64x64 with HTTP 422 - Warns on images < 256x256 (reduced confidence_cap to 0.70) - Warns on grayscale, RGBA, heavily-compressed JPEG - Returns confidence_cap to cap signal confidence appropriately analyze.py: quality gate added as Layer 4 between MIME validation and cache lookup. Prevents wasted computation and inaccurate analysis on solid-color, tiny, or corrupt images.f31a0c8
-
fix: audit pass — unused imports, None crash guard, emojis, accuracy claims, broken f-strings
206dd1a
-
Optimize file validation order for DoS protection
- Validate file size before MIME type check - Fail fast on oversized files to prevent resource exhaustion - Improved security against DoS attacks83ab126
-
Add file validation utility (#4)
- Implement MIME type validation using python-magic - Add file size limit enforcement (50MB max) - Create FileValidationError for validation failures - Add comprehensive unit tests with fixtures - Use centralized logger for validation events Security features: - Validates actual file content, not just extension - Prevents renamed malicious files (.exe -> .jpg) - Enforces memory-safe size limits Closes #4219cb99
-
Initial commit: Project structure and documentation
- Add professional folder structure (backend, frontend, docs) - Create README with project overview and roadmap - Add MIT license for open-source compliance - Configure .gitignore for Python, env files, and privacy - Set up placeholder files for modular architecture68e39ae