fix: upgrade libgnutls30 and libssh2-1 to fix Trivy CVEs

[Kaiohz]

Summary

• Upgrade libgnutls30 and libssh2-1 in Docker image to fix 3 CRITICAL CVEs blocking CD
• CVE-2026-33845, CVE-2026-42010 (gnutls), CVE-2026-7598 (libssh2)
• Same code as merged PR BRIC-19: Add RAGAnythingBricks MCP server #32, just adding the Dockerfile security fix

[Kaiohz]

🔍 Code Review — PR #33

Score : 8/10 🟢

---

✅ Points positifs

1. Architecture hexagonale respectée — Le port BricksApiPort (abstraction domaine) + adapter BricksApiAdapter (infrastructure) suit parfaitement le pattern existant. Propre et cohérent.

2. Tests exhaustifs — 431 lignes de tests pour l'adapter, 224 pour le port/model, 97 pour le use case list, 206 pour publish, 237 pour read, 322 pour les MCP tools. Couverture des cas normaux ET des erreurs (401, 403, 404, timeout, connection error). Bravo.

3. Dry-run par défaut — BRICKS_PUBLISH_DRY_RUN=true en dev, c'est un excellent choix. On ne publie jamais accidentellement chez Bricks.

4. Gestion des erreurs distinguée — Chaque code HTTP a son exception Python sémantique (PermissionError, FileNotFoundError, ConnectionError, TimeoutError). C'est beaucoup plus exploitable que des RuntimeError génériques.

5. Cleanup des fichiers temporaires — Le finally: os.unlink(tmp_path) dans ReadBricksDocumentUseCase assure qu'on ne leak pas de fichiers même en cas d'erreur. Bon reflex.

6. Documentation à jour — README mis à jour avec le 4e MCP server, les nouveaux tools, la config Bricks. C'est souvent oublié.

7. Dockerfile CVE fix — Le apt-get upgrade -y libgnutls30 libssh2-1 est propre et ciblé. Pas de full upgrade.

---

⚠️ Points à améliorer

1. urllib au lieu de httpx — Le reste du projet utilise probablement des clients modernes. urllib.request est verbeux et synchrone (wrappé dans asyncio.to_thread). C'est fonctionnel, mais un client async natif (httpx.AsyncClient) serait plus idiomatique et performant dans un contexte FastAPI/async. Impact moyen — ça marche, mais c'est un écart de style.

2. download_document fait 2 appels API — Pour télécharger un document, on appelle d'abord list_project_documents pour résoudre l'URL pré-signée, puis on télécharge. C'est correct car l'URL est dans la réponse de list, mais ça signifie qu'on récupère TOUS les documents du projet pour en télécharger un seul. Si un projet a 500 docs, c'est un overhead. Suggestion : Ajouter un cache court (TTL 5min) sur list_project_documents, ou passer l'URL directement dans le tool MCP.

3. Pas de retry/backoff — Les appels API vers Bricks n'ont aucun retry. Si l'API retourne un 502/503 transient, c'est échec direct. Un retry simple avec backoff exponentiel améliorerait la résilience.

4. workflow_name default incohérent — Dans le MCP tool, workflow_name default = "agent-haiku-files-v1", mais dans la doc README c'est "haiku-files". Le use case default est aussi "agent-haiku-files-v1". Il faut harmoniser.

5. content: dict sans validation — Le tool publish_section_version accepte content: dict sans schéma Pydantic. Un dict brut, c'est fragile. Un PublishContent model avec validation apporterait de la robustesse, surtout pour un MCP tool exposé publiquement.

6. Typo mineure — mcp_bricks_tools.py ligne 36: Returns: dans la docstring de list_bricks_documents est vide (juste "Liste des documents du projet Bricks avec métadonnées" mais le champ Returns n'a pas de description du type de retour).

---

💡 Suggestions (nice-to-have)

• Typing des retours MCP — list_bricks_documents retourne list (non typé). Utiliser list[BricksDocumentInfo] serait plus explicite et aiderait les clients MCP à comprendre le schéma.
• Connection pooling — Si httpx est adopté, un client partagé avec connection pool réduirait la latence.
• Health check Bricks — Ajouter un endpoint /health check qui vérifie la connectivité Bricks (optionnel).

---

🏁 Verdict

8/10 — PR solide, bien structurée, bien testée. L'intégration Bricks suit les patterns existants du projet. Les points négatifs sont des améliorations possibles, pas des bloqueurs. Les 2 points les plus worth addressing avant merge :

1. Harmoniser les defaults workflow_name
2. Considérer un cache pour list_project_documents dans download_document

Approuvé avec suggestions mineures. 👍