Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 18 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

PictoPy is an advanced desktop gallery application that combines the power of Tauri, React, and Rust for the frontend with a Python backend for sophisticated image analysis and management.

# Want to Contribute? 😄
# Want to Contribute?

&nbsp;&nbsp;&nbsp;<a href="https://discord.gg/hjUhu33uAn"><img src="https://github.com/user-attachments/assets/3ed93273-5055-4532-a524-87a337a4fbba" height="40"></a>

Expand Down Expand Up @@ -62,4 +62,20 @@ Handles file system operations and provides a secure bridge between the frontend

---

Our Code of Conduct: [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)
## Installation

To run the app locally:

1. Install all dependencies (Backend, Docs, and Microservices):
```bash
pip install -r requirements.txt
```

2. Serve the documentation:
```bash
mkdocs serve
```

3. Open your browser and navigate to `http://127.0.0.1:8000`.
Comment on lines +65 to +79
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check if CONTRIBUTING.md exists and contains startup/run instructions
if [ -f "CONTRIBUTING.md" ]; then
  echo "=== Searching for startup/run instructions in CONTRIBUTING.md ==="
  rg -i "run|start|server|backend|frontend" CONTRIBUTING.md -A 2 -B 1
else
  echo "CONTRIBUTING.md not found"
fi

# Also check if there are setup scripts or additional docs
echo -e "\n=== Checking for setup-related files ==="
fd -type f \( -name "*setup*" -o -name "*install*" -o -name "*run*" -o -name "*start*" \) | head -30

# Check for other common documentation files
echo -e "\n=== Checking for common docs files ==="
fd -type f \( -name "*.md" \) -path "*/docs/*" -o -name "*SETUP*" -o -name "*RUN*" | head -20

# Check README.md full content around Installation section
echo -e "\n=== Checking README.md context ==="
cat -n README.md | head -100

Repository: AOSSIE-Org/PictoPy

Length of output: 4718


Clarify what the Installation section accomplishes.

The Installation section is minimal and potentially confusing about scope:

  1. Step 2 (mkdocs serve) serves the documentation site, not the application itself. This is unclear without additional context.
  2. The section doesn't explain what users should do after these steps—how to run the backend API or desktop app isn't addressed here.

While the README does direct contributors to CONTRIBUTING.md (line 10) for detailed setup, the Installation section itself should clarify that these steps set up the documentation environment. Consider adding a brief note like: "The steps above serve the documentation. For running the backend API or desktop application, see CONTRIBUTING.md."

🤖 Prompt for AI Agents
In README.md around lines 65 to 79, clarify that the listed commands set up and
serve the documentation site (not the application) and point readers to
CONTRIBUTING.md for running the backend API or desktop app; update the
Installation section to explicitly state that step 2 runs MkDocs to serve docs
locally, and add one sentence directing users to CONTRIBUTING.md for full
backend/desktop setup and runtime instructions.


Our Code of Conduct: [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)
3 changes: 3 additions & 0 deletions requirements.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
-r backend/requirements.txt
-r docs/requirements.txt
-r sync-microservice/requirements.txt
Comment on lines +1 to +3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify subdirectory requirement files exist and check their content
echo "=== Checking subdirectory requirement files ==="
for file in backend/requirements.txt docs/requirements.txt sync-microservice/requirements.txt; do
  if [ -f "$file" ]; then
    echo "✓ Found: $file"
    echo "  Content:"
    head -20 "$file" | sed 's/^/    /'
  else
    echo "✗ Missing: $file"
  fi
done

Repository: AOSSIE-Org/PictoPy

Length of output: 1264


🏁 Script executed:

#!/bin/bash
# List all files in repository to understand structure
echo "=== Repository structure ==="
git ls-files | head -50

Repository: AOSSIE-Org/PictoPy

Length of output: 1754


🏁 Script executed:

#!/bin/bash
# Check for more details on h11 versions in requirements
echo "=== h11 versions across requirement files ==="
rg "h11==" backend/requirements.txt sync-microservice/requirements.txt docs/requirements.txt 2>/dev/null || echo "h11 not found in some files"

echo -e "\n=== Complete backend/requirements.txt ==="
cat backend/requirements.txt 2>/dev/null || echo "Cannot read backend/requirements.txt"

Repository: AOSSIE-Org/PictoPy

Length of output: 1583


🌐 Web query:

h11 0.14.0 CVE vulnerability DoS chunked encoding

💡 Result:

Short answer: This is CVE-2025-43859. h11 (≤0.14.0) accepted malformed Chunked-Encoding terminators (it accepted any two bytes instead of strict CRLF), which can enable HTTP request smuggling when paired with a buggy proxy — not a simple DoS. The bug was disclosed Apr 24, 2025 and patched in h11 0.16.0; upgrade h11 to ≥0.16.0 (or fix/update any reverse/proxy that might parse chunked bodies). [1][2][3]

Sources:

  • GitHub advisory (h11: malformed Chunked-Encoding bodies, published Apr 24, 2025). [1]
  • CVE / vulnerability summaries (CVE-2025-43859 details and impact). [2]
  • Vendor/advisories and DB entries showing patch to 0.16.0 and mitigation guidance. [3]

References:
[1] GitHub Advisory: h11 accepts some malformed Chunked-Encoding bodies.
[2] CVE-2025-43859 vulnerability summaries (e.g., Vulert / Scout / Enginsight).
[3] IBM security bulletin mentioning h11-0.14.0 and CVE-2025-43859.


🌐 Web query:

Jinja2 3.1.4 sandbox breakout vulnerability

💡 Result:

Short summary

  • Jinja 3.1.4 is vulnerable to sandbox breakouts (multiple issues) that let an attacker who can supply template content (and in one case also a filename) escape the sandbox and potentially execute arbitrary Python. [1][2][3]

Impact

  • Only exploitable when an application renders untrusted templates (or when an attacker can control template filename + content for the filename issue). If your app never renders untrusted templates, risk is lower; otherwise treat as high-risk. [2][3]

Vulnerabilities / identifiers

  • CVE-2024-56326 — sandbox breakout via indirect reference to str.format (affects <= 3.1.4). [3]
  • CVE-2024-56201 — sandbox/compiler breakout via malicious filenames (affects <= 3.1.4; fixed in 3.1.5). [2]
  • GitHub/other advisories describe an additional attr-filter bypass fixed in 3.1.6 (CVE-2025-27516). [1][4]

Action you should take

  1. Upgrade Jinja to the fixed release: 3.1.6 (recommended) — this contains fixes for the format/attr filter sandbox bypass and related issues. If you cannot go to 3.1.6 immediately, at minimum upgrade to 3.1.5 to fix the filename compiler issue, but 3.1.6 is the complete fix. [1][2][3][4]
  2. If you cannot upgrade immediately, stop processing untrusted templates and remove/disable custom filters that might call str.format or accept attribute-callable references. Audit places that accept template content or template filenames from users. [1][3]
  3. After upgrading, test template rendering paths and CI/CD package updates to ensure the new version is deployed.

References

  • GitHub Advisory (indirect format method / CVE-2024-56326). [3]
  • GitHub Advisory (malicious filenames / CVE-2024-56201). [2]
  • Snyk Jinja2 vulnerability notes (summary and recommended versions). [1]
  • GitHub Advisory / CVE-2025-27516 (attr filter bypass fixed in 3.1.6). [4]

If you want, tell me your current jinja2 version (pip show jinja2) and I can give exact pip/poetry/apt/yum upgrade commands.


Update backend/requirements.txt to fix critical vulnerabilities; subdirectory files exist but have inconsistent dependency versions.

All three referenced subdirectory requirement files exist. However, backend/requirements.txt contains critical vulnerabilities:

Meanwhile, sync-microservice/requirements.txt already uses patched versions (h11==0.16.0, Jinja2==3.1.6). Update backend/requirements.txt to align with these patched versions before merging.

🧰 Tools
🪛 OSV Scanner (2.3.0)

[HIGH] 1-1: jinja2 3.1.4: Jinja2 vulnerable to sandbox breakout through attr filter selecting format method

(GHSA-cpwx-vrp4-4pq7)


[HIGH] 1-1: jinja2 3.1.4: Jinja has a sandbox breakout through malicious filenames

(GHSA-gmj6-6f8f-6699)


[HIGH] 1-1: jinja2 3.1.4: Jinja has a sandbox breakout through indirect reference to format method

(GHSA-q2x7-8rv6-6q7h)


[HIGH] 1-1: certifi 2024.2.2: undefined

(PYSEC-2024-230)


[HIGH] 1-1: certifi 2024.2.2: Certifi removes GLOBALTRUST root certificate

(GHSA-248v-346w-9cwc)


[CRITICAL] 1-1: h11 0.14.0: h11 accepts some malformed Chunked-Encoding bodies

(GHSA-vqfr-h8mv-ghfj)


[HIGH] 1-1: protobuf 5.26.1: protobuf-python has a potential Denial of Service issue

(GHSA-8qvm-5x2c-j2w7)


[HIGH] 1-1: python-multipart 0.0.9: Denial of service (DoS) via deformation multipart/form-data boundary

(GHSA-59g5-xgcq-4qw3)


[HIGH] 1-1: setuptools 66.1.1: undefined

(PYSEC-2025-49)


[HIGH] 1-1: setuptools 66.1.1: setuptools has a path traversal vulnerability in PackageIndex.download that leads to Arbitrary File Write

(GHSA-5rjg-fvgr-3xxf)


[HIGH] 1-1: setuptools 66.1.1: setuptools vulnerable to Command Injection via package URL

(GHSA-cx63-2mw6-8hw5)


[HIGH] 1-1: starlette 0.37.2: Starlette has possible denial-of-service vector when parsing large files in multipart forms

(GHSA-2c2j-9gv5-cj73)


[HIGH] 1-1: starlette 0.37.2: Starlette Denial of service (DoS) via multipart/form-data

(GHSA-f96h-pmfr-66vw)


[HIGH] 1-1: starlette 0.47.2: Starlette vulnerable to O(n^2) DoS via Range header merging in starlette.responses.FileResponse

(GHSA-7f5h-v6xp-fcq8)


[HIGH] 1-1: urllib3 2.5.0: urllib3 streaming API improperly handles highly compressed data

(GHSA-2xpw-w6gg-jr37)


[HIGH] 1-1: urllib3 2.5.0: urllib3 allows an unbounded number of links in the decompression chain

(GHSA-gm62-xv2j-4w53)

🤖 Prompt for AI Agents
In requirements.txt around lines 1 to 3, backend/requirements.txt currently pins
vulnerable h11==0.14.0 and Jinja2==3.1.4; update backend/requirements.txt to
match the patched versions used by sync-microservice (h11==0.16.0 and
Jinja2==3.1.6), ensure no duplicate/conflicting pins remain across subdirectory
requirement files, then reinstall or run your dependency check (pip install -r
backend/requirements.txt or CI dependency job) and run the test suite/linters to
confirm no breakage before merging.