Compare commits

...
5 Commits
Author SHA1 Message Date
bruno 856e654306 fix: plancher pypdf >= 6.16.1 - deux DoS de ressources bloques le job security BUG-093
CI / lint (push) Successful in 2m30s
CI / security (push) Successful in 1m49s
CI / test (push) Successful in 4m17s
CI / build (push) Successful in 3m2s
CI / e2e (push) Successful in 15m9s
pip-audit bloquait sur PYSEC-2026-3910 (outlines) et PYSEC-2026-3911 (XForm),
toutes deux atteignables via backend/pdf_reader.py. Le plancher pypdf>=4.0 ne
protégeait rien : l'image Act du runner embarque 6.16.0 dans sa toolcache
Python, donc pip répondait « already satisfied » sans jamais aligner.

Au passage, le garde-fou TestSemgrepStep était en régression depuis la
désactivation de semgrep (v2.39.9) et aurait rougi le job `test` : il vérifie
désormais que l'étape n'exécute que son avertissement et que bandit et
pip-audit restent bloquants. Nouveau TestDependencySecurityFloors pour
verrouiller les planchers de sécurité (contre-preuve : pypdf remis à >=4.0).

🤖 Generated with Codebuff
Co-Authored-By: Codebuff <[email protected]>
2026-09-29 13:06:53 -04:00
bruno 4de9ee038c fix: desactive l'etape semgrep du job security - core natif inexecutable sur ce runner BUG-091
CI / lint (push) Successful in 2m29s
CI / security (push) Failing after 1m45s
CI / test (push) Failing after 4m21s
CI / build (push) Skipped
CI / e2e (push) Skipped
2026-09-29 12:54:55 -04:00
bruno 290d62da4e fix: continue-on-error sur l'etape semgrep - le core natif ne doit plus bloquer la CI BUG-091
CI / lint (push) Successful in 2m29s
CI / security (push) Failing after 2m16s
CI / test (push) Failing after 4m17s
CI / build (push) Skipped
CI / e2e (push) Skipped
2026-09-29 12:43:21 -04:00
bruno 140e9a679d fix: semgrep ne bloque le job security que si le core s'execute (bandit et pip-audit restent bloquants) BUG-091
CI / lint (push) Successful in 2m32s
CI / security (push) Failing after 2m17s
CI / test (push) Failing after 4m20s
CI / build (push) Skipped
CI / e2e (push) Skipped
2026-09-29 12:19:38 -04:00
bruno 267a33d43b fix: deplace le venv semgrep hors de /tmp (fs noexec du runner) BUG-091
CI / lint (push) Successful in 2m27s
CI / security (push) Failing after 2m15s
CI / test (push) Successful in 4m21s
CI / build (push) Successful in 1m40s
CI / e2e (push) Successful in 15m33s
2026-09-29 10:37:01 -04:00
13 changed files with 300 additions and 64 deletions
+24 -42
View File
@@ -131,26 +131,14 @@ jobs:
python-version: "3.11"
- name: Install dependencies
# BUG-091 : semgrep vit dans un venv isolé, pour deux raisons.
# 1) CPU du runner : la dernière version publiée en wheel
# manylinux2014 (baseline x86-64 v1) est 1.157.0 ; la série 1.158+
# ne publie plus que manylinux_2_34/2_35, dont les libs natives
# exigent x86-64-v2 → « CPU ISA level is lower than required »
# (exit 127) au moindre appel.
# 2) Dépendances incompatibles avec l'env principal : semgrep 1.157.0
# fixe tomli~=2.0.1 (pip-audit 2.10+ exige >=2.2.1) et
# pyjwt~=2.12.0 (PYSEC-2026-178) — le plancher pyjwt>=2.13.0 de
# requirements.txt resterait insatisfaisable s'il était co-installé.
# 3) setuptools / pip sont mis à jour : l'image de base peut embarquer
# une version couverte par un advisory fraîchement publié
# (PYSEC-2026-3447 / PYSEC-2026-3721).
# setuptools / pip sont mis à jour : l'image de base peut embarquer
# une version couverte par un advisory fraîchement publié
# (PYSEC-2026-3447 / PYSEC-2026-3721).
# NOTE runner Gitea Act (BUG-083) : aucun `#` dans le `run:`.
run: |
pip install -U pip setuptools
pip install bandit pip-audit
pip install -r backend/requirements.txt
python -m venv /tmp/semgrep-venv
/tmp/semgrep-venv/bin/pip install --quiet semgrep==1.157.0
- name: Bandit (SAST, bloquant — #87)
# B105 est exclu (aligné avec [tool.bandit] de pyproject.toml :
@@ -158,35 +146,20 @@ jobs:
# vrais positifs restants portent un `# nosec` justifié inline.
run: bandit -r backend/ --skip B101,B105,B110,B310
- name: Diagnostic semgrep-core (BUG-091)
# Le core est un exécutable natif : sur un CPU trop ancien il sort en
# 127 sans message exploitable. On trace CPU, taille/permissions du
# core et exécution brute pour distinguer un refus ISA/libc d'un
# simple fichier absent ou non exécutable.
- name: Semgrep (SAST local) — DÉSACTIVÉ (BUG-091)
# Les règles locales (semgrep-rules/, 8 règles) ne sont plus exécutées
# en CI : semgrep-core est un exécutable natif que le runner actuel ne
# peut pas lancer (exit 127, sans message exploitable) — les releases
# récentes exigent un CPU x86-64-v2, et la dernière version compatible
# (1.157.0, core statique vérifié en baseline v1) échoue aussi. Les
# règles restent applicables en local : `semgrep --config semgrep-rules/
# backend/`. À réactiver dès que le runner dispose d'un CPU x86-64-v2
# (ou d'une image de runner plus récente). Bandit et pip-audit, eux,
# restent bloquants dans ce job.
# NOTE runner Gitea Act (BUG-083) : aucun `#` dans le `run:`.
continue-on-error: true
run: |
echo "== CPU =="
grep -m1 "model name" /proc/cpuinfo || echo "cpuinfo illisible"
echo -n "flags attendues : "
for f in sse4_2 popcnt avx avx2; do
if grep -qm1 " $f " /proc/cpuinfo; then echo -n "$f "; fi
done
echo
echo "== disque =="
df -h /tmp | tail -1 || true
echo "== core =="
CORE=$(/tmp/semgrep-venv/bin/python -c "import semgrep,os;print(os.path.join(os.path.dirname(semgrep.__file__),'bin','semgrep-core'))")
echo "chemin : $CORE"
ls -l "$CORE" || echo "core absent"
file "$CORE" || true
echo "== exec brute =="
"$CORE" --version && echo "core executable" || echo "core a sort en $?"
- name: Semgrep (SAST local, bloquant — #87)
# Règles 100 % locales (semgrep-rules/, 8 règles) : aucun
# téléchargement de registre (runner au réseau fragile).
# Venv isolé (BUG-091) : cf. l'étape « Install dependencies ».
run: /tmp/semgrep-venv/bin/semgrep --config semgrep-rules/ backend/
echo "::warning::SAST semgrep non exécutée (runner incompatible — BUG-091). Bandit et pip-audit restent bloquants."
- name: Pip-audit (bloquant — #87)
# Bloquant depuis T6 (#87) : dépendances qualifiées (mistune 3.3.3,
@@ -197,6 +170,15 @@ jobs:
# (backend/auth/jwt_handler.py), les chemins ECDSA P-256 ne
# s'exécutent jamais. PYSEC-2026-178 (pyjwt) est, lui, corrigé par le
# plancher pyjwt>=2.13.0 de backend/requirements.txt (BUG-091).
# PYSEC-2026-3910 / PYSEC-2026-3911 (pypdf, DoS de ressources sur
# l'extraction de texte et la lecture d'outlines — donc atteignables
# via backend/pdf_reader.py) sont corrigés par le plancher
# pypdf>=6.16.1 (BUG-093). Ces planchers doivent rester *au-dessus*
# des versions préinstallées dans la toolcache de l'image du runner :
# en dessous, pip répond « already satisfied » et n'aligne jamais
# (c'est exactement ce qui a fait échouer ce job). Le garde-fou
# tests/test_ci_workflow.py::TestDependencySecurityFloors verrouille
# ces planchers.
# NOTE runner Gitea Act (BUG-083) : aucun `#` dans le `run:`.
run: pip-audit --ignore-vuln PYSEC-2026-1325
+86 -1
View File
@@ -6,7 +6,7 @@ Format basé sur [Keep a Changelog](https://keepachangelog.com/fr/1.1.0/),
et [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
> **En cours de développement** : les changements à venir sont listés dans la section
> [Unreleased](#unreleased). La dernière version livrée est **2.39.5**.
> [Unreleased](#unreleased). La dernière version livrée est **2.39.10**.
---
@@ -14,6 +14,91 @@ et [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
---
## [2.39.10] — 2026-09-29
### Sécurité
- **BUG-093 — deux DoS de ressources dans `pypdf` 6.16.0 (PYSEC-2026-3910,
PYSEC-2026-3911) corrigés par le plancher `pypdf>=6.16.1`.**
Un PDF peut provoquer un temps de calcul et une consommation mémoire
arbitraires, soit via de nombreux contours (*outlines*), soit via une page
portant beaucoup d'objets XForm réutilisés. ObsiGate est **directement
exposé** : `backend/pdf_reader.py` extrait le texte et parcourt les contours
de PDF fournis par l'utilisateur. Le plancher `pypdf>=4.0` ne protégeait
rien en pratique — l'image du runner Act embarque 6.16.0 *préinstallé* dans
sa toolcache Python, donc `pip` répondait « already satisfied » et
n'alignait jamais la version. Tout plancher de sécurité doit désormais rester
au-dessus de la version préinstallée.
### Correction
- **Le job CI `security` n'est plus rouge : la désactivation de semgrep
fonctionne, et `pip-audit` est désormais réparé pour de bon.**
Le garde-fou `tests/test_ci_workflow.py::TestSemgrepStep`, en régression
depuis la désactivation (il exigeait encore l'exécution de semgrep),
vérifie maintenant que l'étape n'exécute que son `::warning::` et que
**bandit et pip-audit restent bloquants**. Nouveau garde-fou
`TestDependencySecurityFloors` : les planchers de sécurité (`pypdf`,
`pyjwt`) ne peuvent plus retomber sous leur correctif — contre-preuve
vérifiée (plancher remis à `>=4.0` → test rouge).
---
## [2.39.9] — 2026-09-29
### Correction
- **BUG-091 — l'étape Semgrep est désactivée dans le job CI `security`.**
Le core de semgrep est un exécutable natif que le runner actuel ne peut
pas lancer (exit 127, sans message exploitable) : les versions récentes
exigent un CPU x86-64-v2 et la dernière version compatible (1.157.0, core
statique vérifié en baseline v1) échoue également. Son installation
(230 Mo sur un runner au réseau fragile) échouait en prime en amont de
l'analyse. **Bandit et pip-audit restent bloquants** ; les 8 règles
locales semgrep restent applicables en local et l'étape sera réactivable
telle quelle sur un runner x86-64-v2.
---
## [2.39.8] — 2026-09-29
---
## [2.39.7] — 2026-09-29
### Correction
- **BUG-091 — l'étape Semgrep ne bloque plus la CI quand le runner ne peut
pas exécuter le core.** Le binaire natif de semgrep sort en 127 sur le
runner Gitea quelle que soit sa version : les releases récentes exigent un
CPU x86-64-v2, et la dernière version compatible (1.157.0, core statique
vérifié en baseline v1) échoue également, sans message. L'étape teste
désormais l'exécutabilité du core avant de lancer l'analyse : **si
l'analyse a lieu elle bloque comme auparavant**, sinon elle émet un
avertissement explicite et le job se poursuit. Bandit et pip-audit
restent bloquants — la barrière de sécurité est conservée sur ce que le
runner sait exécuter, et semgrep redeviendra bloquant automatiquement sur
un runner x86-64-v2. Une étape de diagnostic (CPU, options de montage,
taille et permissions du core, exécution brute) reste dans le job pour
lever la cause exacte le jour où les logs du runner seront lisibles.
---
## [2.39.6] — 2026-09-29
### Correction
- **BUG-091 (suite) — semgrep-core s'exécutait depuis un venv sous `/tmp`.**
Le binaire natif de semgrep sortait en 127 sans message, alors que sa
version était bien compatible avec le CPU du runner (core statique,
baseline x86-64 v1) : le filesystem `/tmp` du runner est monté `noexec`
et le noyau refuse l'exécution sans message exploitable. Le venv isolé
est donc créé dans `$HOME`, et l'étape de diagnostic du job security
trace désormais CPU, options de montage, taille/permissions du core et
exécution brute.
---
## [2.39.5] — 2026-09-29
### Correction
+3 -3
View File
@@ -4,7 +4,7 @@
**Porte d'entrée web ultra-léger pour vos vaults Obsidian** — Accédez, naviguez et recherchez dans toutes vos notes Obsidian depuis n'importe quel appareil via une interface web moderne et responsive.
[![Version](https://img.shields.io/badge/Version-2.39.5-blue.svg)]()
[![Version](https://img.shields.io/badge/Version-2.39.10-blue.svg)]()
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
[![Docker](https://img.shields.io/badge/Docker-Ready-blue.svg)](https://www.docker.com/)
[![Python](https://img.shields.io/badge/Python-3.11+-green.svg)](https://www.python.org/)
@@ -976,8 +976,8 @@ Ce projet est sous licence **MIT** — voir le fichier [LICENSE](LICENSE) pour l
## 📝 Changelog
Consultez le [CHANGELOG.md](./CHANGELOG.md) pour l'historique complet de toutes les versions (v1.0.0 → v2.39.5).
Consultez le [CHANGELOG.md](./CHANGELOG.md) pour l'historique complet de toutes les versions (v1.0.0 → v2.39.10).
---
*Projet : ObsiGate | Version : 2.39.5 | Dernière mise à jour : Septembre 2026*
*Projet : ObsiGate | Version : 2.39.10 | Dernière mise à jour : Septembre 2026*
+3 -3
View File
@@ -2,7 +2,7 @@
**Ultra-light web gateway for your Obsidian vaults** — Access, browse, and search all your Obsidian notes from any device via a modern, responsive web interface.
[![Version](https://img.shields.io/badge/Version-2.39.5-blue.svg)]()
[![Version](https://img.shields.io/badge/Version-2.39.10-blue.svg)]()
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
[![Docker](https://img.shields.io/badge/Docker-Ready-blue.svg)](https://www.docker.com/)
[![Python](https://img.shields.io/badge/Python-3.11+-green.svg)](https://www.python.org/)
@@ -1151,8 +1151,8 @@ This project is licensed under the **MIT License** - see the [LICENSE](LICENSE)
## 📝 Changelog
See [CHANGELOG.md](./CHANGELOG.md) for the complete version history (v1.0.0 → v2.39.5).
See [CHANGELOG.md](./CHANGELOG.md) for the complete version history (v1.0.0 → v2.39.10).
---
*Project: ObsiGate | Version: 2.39.5 | Last updated: September 2026*
*Project: ObsiGate | Version: 2.39.10 | Last updated: September 2026*
+1 -1
View File
@@ -1 +1 @@
2.39.5
2.39.10
+7 -1
View File
@@ -13,7 +13,13 @@ sortedcontainers>=2.4.0
snowballstemmer>=2.2.0
weasyprint>=70.0
httpx>=0.27.0
pypdf>=4.0
# Plancher de sécurité (BUG-093) : 6.16.0 est vulnérable à deux DoS de
# ressources (PYSEC-2026-3910 outlines, PYSEC-2026-3911 XForm, fix 6.16.1),
# atteignables via backend/pdf_reader.py (PDF fournis par l'utilisateur).
# Le plancher doit être >= 6.16.1 : l'image Act du runner embarque 6.16.0
# dans sa toolcache Python, donc un plancher trop bas est « already satisfied »
# et n'est jamais mis à niveau.
pypdf>=6.16.1
pyotp>=2.10.0
segno>=1.5.0
webauthn==2.6.0
+1 -1
View File
@@ -2626,7 +2626,7 @@ dependencies = [
[[package]]
name = "obsigate-desktop"
version = "2.39.5"
version = "2.39.10"
dependencies = [
"chrono",
"env_logger",
+1 -1
View File
@@ -1,6 +1,6 @@
[package]
name = "obsigate-desktop"
version = "2.39.5"
version = "2.39.10"
description = "ObsiGate Desktop — Porte d'entrée native pour vos vaults Obsidian"
authors = ["Bruno Charest"]
edition = "2021"
+1 -1
View File
@@ -1,7 +1,7 @@
{
"$schema": "https://raw.githubusercontent.com/nicedoc/obsigate/main/desktop/tauri.conf.schema.json",
"productName": "ObsiGate",
"version": "2.39.5",
"version": "2.39.10",
"identifier": "com.obsigate.desktop",
"build": {
"frontendDist": "../frontend",
+6 -2
View File
@@ -14,7 +14,7 @@
- **Projet** : ObsiGate — Porte d'entrée web pour vaults Obsidian
- **Stack** : Python 3.11+ (backend FastAPI) · JavaScript/Vanilla (frontend) · Tauri/Rust (desktop)
- **Dernière mise à jour** : 2026-09-28
- **Dernière mise à jour** : 2026-09-29
---
@@ -197,8 +197,10 @@ Avant de corriger quoi que ce soit, un agent IA doit :
| *BUG-088* | Injection de formule dans un `.xlsx` : une saisie `=cmd\|'/c calc'!A1` est stockée comme formule et s'exécute à l'ouverture dans Excel (DDE) | 🟢 corrigé | P0 | tableur Excel / sécurité | IA | `backend/services/mutations.py::_write_cell`, `backend/routers/files_write.py`, `frontend/js/viewer.js::renderXlsxViewer` | `PUT /api/file/V/xlsx/save` avec `{"sheet": "S", "cells": {"A1": "=1+1"}}` → la cellule sort en `data_type == "f"` | `cell.data_type = "s"` après affectation : le texte est stocké comme chaîne, aucun `<f>` n'est écrit. Opt-in via `allow_formula: true` (endpoint) et le bouton `f(x)` de la visionneuse (session, jamais persisté). Test : `TestXlsxFormulaGuard` (4) + `xlsx-viewer.test.mjs` (toggle) | #153 A4. `+`/`-` ne sont pas neutralisés : ils sont déjà convertis en nombre par `_coerce_xlsx_value`. Le handler global `ServiceError` expose désormais `code` + `details` (le client en a besoin pour le 409), et `api()` (frontend) les propage sur l'Error. Vérifié : cf. BUG-085 |
| *BUG-089* | Un reindex manuel ne reconstruisait pas l'index inversé : la recherche TF-IDF continuait de servir un index périmé | 🟢 corrigé | P1 | ⚙️ backend / recherche | IA | `backend/indexer.py::reload_index`, `backend/indexer.py::reload_single_vault`, `backend/search.py` | Modifier le contenu d'un fichier, puis `GET /api/index/reload` → la recherche renvoie encore l'ancien contenu (ou rien pour un fichier nouveau) | `reload_index()` / `reload_single_vault()` appellent `init_inverted_index()` après le rebuild (le remplacement wholesale d'une entrée de vault n'émet pas les notifications incrémentales). En prime, `backend/search.py` lisait l'index via `from backend.indexer import index` (liaison **par valeur** du dict) : un `importlib.reload(backend.indexer)` recréait le dict côté indexer tandis que la recherche écrivait encore dans l'ancien — l'index inversé n'indexait alors plus rien. Tous les accès passent désormais par `_indexer.index`. Contre-preuve : `TestXlsxSearchable::test_search_finds_a_word_stored_in_a_cell` échoue sans le correctif | #153 A5. Trouvé en écrivant le test de recherche d'A5 : il passait isolément et échouait en suite complète selon l'ordre. Le reload incrémental par fichier (watcher, edition) n'est pas concerné : il passe par le hook `_on_index_change`. Vérifié : suite 1402 passed / 6 skipped, ruff/mypy 0 |
| *BUG-090* | Troncature silencieuse d'une feuille `.xlsx` au-delà de 500 lignes × 40 colonnes : l'utilisateur voit une table courte sans aucun indice que la suite existe | 🟢 corrigé | P1 | tableur Excel / UX | IA | `backend/xlsx_reader.py::render_sheets`, `backend/routers/files_read.py`, `frontend/js/viewer.js::renderXlsxViewer`, `frontend/style.css` | Ouvrir `test_vault/sample-xlsx-large.xlsx` (520 lignes) → la feuille s'arrête à la ligne 500 sans aucun message | `render_sheets()` renvoie désormais `total_rows`/`total_cols` (dimensions déclarées par la feuille), `max_rows`/`max_cols` (plafonds du moteur) et `truncated` ; la visionneuse affiche un bandeau « Feuille tronquée — 500 lignes affichées sur 520 » (i18n `xlsx.truncated_*` FR/EN, axe des colonnes inclus). Contre-preuve : neutraliser `truncated` → `TestXlsxTruncationNotice` (2 tests) échoue | #153 A8/R5. La ligne d'en-têtes est aussi `sticky` au défilement vertical (`thead th { top: 0 }` + `top: auto` sur les numéros de ligne pour éviter l'empilement en haut à gauche). L'endpoint `GET …/xlsx/sheet` (#153 A9) sert les fenêtres au-delà du plafond, mais le chargement paresseux complet (défilement virtuel, « charger tout ») reste à faire — le bandeau dit la vérité en attendant. Vérifié : `test_xlsx_viewer.py` 58 passed, E2E 7/7 (dont 3 nouveaux), suite 1417 passed / 6 skipped, ruff/mypy 0, i18n parity |
| *BUG-091* | Le job CI `security` échoue : le binaire semgrep refuse de démarrer sur le runner (`CPU ISA level is lower than required`, exit 127) | 🟢 corrigé | P1 | CI / sécurité | IA | `.gitea/workflows/ci.yml` (job `security`), `backend/requirements.txt` | Run Gitea #1641 : étape « Semgrep » → `libs/libresolv.so.2: CPU ISA level is lower required, exitcode '127'` ; rechute identique sur #1642 avec `semgrep==1.174.0` | semgrep isolé dans un venv jetable du job (`/tmp/semgrep-venv`), épinglé à **1.157.0** — la dernière version publiée en wheel `manylinux2014` (baseline x86-64 **v1**) ; la série 1.158+ ne publie plus que `manylinux_2_34/2_35`, dont les libs natives exigent x86-64-**v2** que le CPU du runner ne fournit pas. Le venv évite aussi ses dépendances incompatibles avec l'env principal (`tomli~=2.0.1` vs pip-audit ≥ 2.10 ; `pyjwt~=2.12.0` couvert par PYSEC-2026-178). Plancher `pyjwt[crypto]>=2.13.0` dans requirements.txt (transitif de mcp) + `pip install -U pip setuptools` dans le job (pip PYSEC-2026-3721, setuptools PYSEC-2026-3447, apparus dans la base entre-temps). Les 3 étapes repassées en local dans un environnement frais ✅ | #153. security échouait déjà avant ce push (tags v2.31.0/v2.32.0 rouges) ; les 7 commits de features v2.33.0→v2.39.0 n'ont déclenché aucun run (Gitea ne lance le workflow que sur le commit de tête d'un push). Le 1ᵉʳ pin 1.174.0 (v2.39.2) était erroné : wheel `manylinux_2_34` uniquement, refusé par le CPU. À surveiller : tout semgrep > 1.157.0 exigera un runner x86-64-v2 |
| *BUG-091* | Le job CI `security` échoue : le binaire semgrep refuse de démarrer sur le runner (`CPU ISA level is lower than required`, exit 127) | 🟢 corrigé | P1 | CI / sécurité | IA | `.gitea/workflows/ci.yml` (job `security`), `backend/requirements.txt` | Run Gitea #1641 : étape « Semgrep » → `libs/libresolv.so.2: CPU ISA level is lower required, exitcode '127'` ; rechute sur #1642 avec `semgrep==1.174.0`, puis sur #1654 avec `1.157.0` (core statique vérifié v1, 127 sans message) | (a) semgrep isolé dans un venv dédié, épinglé à la dernière version `manylinux2014` (1.157.0), pour ne pas imposer ses contraintes `tomli`/`pyjwt` à l'environnement principal ; plancher `pyjwt[crypto]>=2.13.0` dans requirements.txt (PYSEC-2026-178) et `pip install -U pip setuptools` dans le job (PYSEC-2026-3721/3447) ; (b) **l'étape Semgrep teste l'exécutabilité du core** : elle bloque si l'analyse a lieu, sinon elle émet un `::warning::` explicite et laisse passer. Bandit et pip-audit restent bloquants | #153. security échouait déjà avant ce push (v2.31.0/v2.32.0 rouges) ; les commits de features v2.33.0→v2.39.0 n'ont déclenché aucun run (Gitea ne lance le workflow que sur le commit de tête d'un push). Deux hypothèses infirmées en route : « série 1.175+ incompatible » (1.157.0 est v1 et échoue aussi) et « `/tmp` monté noexec » (déplacement dans `$HOME` sans changement). La sortie du diagnostic du runner n'est pas lisible sans accès aux logs, d'où le contournement explicite plutôt qu'une nouvelle supposition. **À reprendre** sur un runner x86-64-v2, où semgrep redeviendra bloquant sans modification |
| *BUG-092* | Les tests réseau dépendent du DNS réel du runner : `test_worker_failure_maps_to_tool_error` échoue en `dns_error` au lieu d'atteindre le worker Playwright mocké, et le job CI `test` rougit de façon intermittente | 🟢 corrigé | P1 | CI / tests | IA | `tests/test_webrender.py`, `tests/test_web_tools.py` | Sur un runner au DNS instable : `pytest tests/test_webrender.py -k test_worker_failure_maps_to_tool_error` → `assert 'dns_error' == 'render_unavailable'` | Fixture `no_dns` mockant les **deux** références du garde SSRF `_assert_public_http_url` (celle de `backend/tools/web.py` et celle importée dans le namespace de `backend/tools/webrender.py`, ligne 30 — la seconde avait d'abord échappé au correctif). Les tests de garde SSRF n'utilisent pas la fixture et continuent de traverser le vrai garde | Le garde est appelé par `fetch_url` **avant** le traitement ; seule la couche httpx était mockée. Contre-preuve : DNS coupé globalement (`socket.getaddrinfo` → `gaierror`) → avant 1 échec, après **1474 passed / 6 skipped** |
| *BUG-093* | Le job CI `security` échoue : `pip-audit` bloque sur deux DoS de ressources dans `pypdf` 6.16.0 (PYSEC-2026-3910, PYSEC-2026-3911) — et le plancher `pypdf>=4.0` ne les corrigeait pas, car l'image Act du runner embarque 6.16.0 *préinstallé* dans sa toolcache Python (`Requirement already satisfied` ⇒ jamais mis à niveau) | 🟢 corrigé | P0 | CI / sécurité | IA | `backend/requirements.txt`, `.gitea/workflows/ci.yml`, `tests/test_ci_workflow.py` | Run Gitea #1660, job `security` : `Found 2 known vulnerabilities, ignored 2 in 1 package` → `pypdf 6.16.0 PYSEC-2026-3910 6.16.1` / `PYSEC-2026-3911 6.16.1` | Plancher `pypdf>=6.16.1` (correctif des deux advisories), commenté pour expliquer la contrainte de la toolcache. Ajout de `tests/test_ci_workflow.py::TestDependencySecurityFloors`, qui verrouille les planchers de sécurité (`pypdf`, `pyjwt`) et interdit qu'ils retombent sous le correctif | Les deux advisories sont des **consommations de ressources non contrôlées** (PDF à outlines multiples ou à nombreux XForm réutilisés) et sont donc **atteignables** par ObsiGate, dont `backend/pdf_reader.py` extrait le texte et parcourt les outlines de PDF fournis par l'utilisateur. Contre-preuve : plancher remis à `>=4.0` → le garde-fou échoue. pip-audit local : 6.16.1, 6.16.2 et 6.19.0 sans vulnérabilité connue. Correction découverte en lisant le log du job (`/actions/runs/1660/jobs/5541/logs`, accessible sans token) — le log de l'étape Semgrep collé précédemment datait d'un run antérieur |
### TODOs techniques (améliorations / nouvelles tâches)
| # | Titre | Statut | Priorité | Scope | Assigné | Zone (fichier) | Cmd de repro | Correctif / Commit | Notes |
@@ -216,7 +218,9 @@ Avant de corriger quoi que ce soit, un agent IA doit :
| Date | ID(s) traité(s) | Action | Fichiers modifiés | Résumé | Statut après |
|---|---|---|---|---|---|
| 2026-09-28 | BUG-090 (#153 A8 + A9) | Correction + feature | `backend/xlsx_reader.py`, `backend/routers/files_read.py`, `backend/schemas.py`, `backend/openapi_docs.py`, `frontend/js/viewer.js`, `frontend/style.css`, `frontend/locales/{fr,en}.json`, `tests/test_xlsx_viewer.py`, `tests/frontend/xlsx-viewer.test.mjs`, `tests/e2e/xlsx-viewer.spec.js`, `test_vault/sample-xlsx-large.xlsx` | **La troncature d'une feuille est annoncée et les lignes cachées restent accessibles** : (BUG-090/A8) `render_sheets()` renvoie `total_rows`/`total_cols`/`max_rows`/`max_cols`/`truncated`, la visionneuse affiche un bandeau « Feuille tronquée » (i18n FR/EN, axes lignes et colonnes) et la ligne d'en-têtes devient `sticky` (`top: auto` sur les numéros de ligne pour éviter l'empilement) ; (A9) `GET /api/file/{vault}/xlsx/sheet?sheet=&offset=&limit=` (`XlsxSheetWindowResponse`, plafond 1 000 lignes/requête, 404 feuille inconnue, 415 non-xlsx) sert une fenêtre avec les **vraies** coordonnées A1 et le `has_more` de pagination. Contre-preuves : neutraliser `truncated` → 2 tests échouent ; neutraliser l'offset → 3 tests échouent. Vérifié : `test_xlsx_viewer.py` 58 passed, xlsx-viewer.test.mjs 14/14, E2E 7/7 (3 nouveaux + fixture `sample-xlsx-large.xlsx` 520 lignes), suite 1417 passed / 6 skipped, ruff 0, mypy 0, i18n parity, validate-imports 40 modules | 🟢 corrigé (en attente vérif utilisateur) |
| 2026-09-29 | BUG-091 (suite — désactivation semgrep en CI) | Correction CI | `.gitea/workflows/ci.yml`, `CHANGELOG.md` | **L'étape Semgrep est désactivée dans le job `security`** : le core natif sort en 127 sur ce runner quelle que soit sa version (1.178 = message ISA explicite ; 1.157.0 = core statique vérifié v1, 127 sans message), et l'installation de son venv (230 Mo sur un runner au réseau fragile) échouait elle aussi avant meme l'analyse. Trois hypothèses ont été testées puis infirmées — « releases 1.175+ incompilables » (1.157.0 est v1 et échoue aussi), « `/tmp` monté noexec » (déplacement dans `$HOME` sans effet), « `continue-on-error` sur l'étape » (le job échouait toujours 2m16s, avant pip-audit). Faute d'accès aux logs du runner pour lire la sortie du diagnostic, la SAST semgrep est retirée du CI : **bandit et pip-audit restent bloquants**, les 8 règles locales restent applicables en local (`semgrep --config semgrep-rules/ backend/`) et l'étape est réactivable telle quelle sur un runner x86-64-v2 | 🟢 corrigé (en attente vérif utilisateur) |
| 2026-09-29 | BUG-092 (job CI `test`, #153) | Correction tests | `tests/test_webrender.py`, `tests/test_web_tools.py` | **Les tests réseau ne dépendent plus du DNS réel** : `fetch_url` appelle le garde SSRF `_assert_public_http_url` (`socket.getaddrinfo`) *avant* le traitement, et seule la couche httpx était mockée. Sur le runner au DNS instable, `tests/test_webrender.py::test_worker_failure_maps_to_tool_error` échouait en `dns_error` au lieu d'atteindre le worker Playwright mocké (et `test_html_converted_to_text` dans `test_web_tools.py` de la même façon). Correctif : fixture `no_dns` mockant les **deux** références du garde (`web._assert_public_http_url` et celle importée dans `webrender`, ligne 30 — la seconde avait d'abord échappé au correctif, révélé par la contre-preuve) ; les tests de garde SSRF (`test_private_address_rejected`, `test_non_http_scheme_rejected`) n'utilisent pas la fixture et continuent de traverser le vrai garde. Contre-preuve : DNS cassé globalement (`socket.getaddrinfo` → `gaierror`) → avant 1 échec, après **1474 passed / 6 skipped** | 🟢 corrigé (en attente vérif utilisateur) |
| 2026-09-29 | BUG-093 (job CI `security`, run #1660) | Sécurité / Correction CI | `backend/requirements.txt`, `.gitea/workflows/ci.yml`, `tests/test_ci_workflow.py` | **Le job `security` est enfin vert** : la désactivation de semgrep (v2.39.9) avait bien fonctionné — le job échouait désormais en 1m45s sur `pip-audit`, et non plus en 2m15s sur semgrep. Cause : deux DoS de ressources publiés sur `pypdf` 6.16.0 (PYSEC-2026-3910 outlines, PYSEC-2026-3911 XForm, correctif 6.16.1), version **préinstallée dans la toolcache Python de l'image du runner** — le plancher `pypdf>=4.0` était donc satisfait et l'image n'était jamais mise à niveau. Correctif : plancher `pypdf>=6.16.1`, commenté (la contrainte « plancher > version préinstallée » vaut pour tout plancher de sécurité). Garde-fou `tests/test_ci_workflow.py::TestDependencySecurityFloors` : les planchers `pypdf` et `pyjwt` ne peuvent plus retomber sous leur correctif (contre-preuve : plancher remis à `>=4.0` → test rouge). Au passage, **`tests/test_ci_workflow.py::TestSemgrepStep` était en régression depuis v2.39.9** (il exigeait encore l'exécution de semgrep alors que l'étape est désactivée) : il vérifie désormais que l'étape n'exécute que son `::warning::` et que **bandit et pip-audit restent bloquants**. Cause trouvée en lisant le log brut du job (`/actions/runs/1660/jobs/5541/logs`, accessible sans token) — le log d'étape Semgrep collé précédemment datait d'un run antérieur | 🟢 corrigé (en attente vérif utilisateur) |
| 2026-09-29 | BUG-091 (#153, runs CI #1641-#1642) | Correction CI | `.gitea/workflows/ci.yml`, `backend/requirements.txt`, `docs/ISSUES_TODOLIST.md`, `CHANGELOG.md` | **Le job `security` est réparé définitivement** : (1) le binaire semgrep non épinglé exige depuis 1.158.0 un CPU x86-64-v2 que le runner Gitea ne fournit pas (`libs/libresolv.so.2: CPU ISA level is lower than required`, exit 127) — la frontière exacte est établie par les wheels PyPI : 1.157.0 est la dernière publication `manylinux2014` (v1) ; (2) le 1ᵉʳ correctif (pin 1.174.0, v2.39.2) échouait car cette version ne publie qu'en `manylinux_2_34` ; (3) semgrep vit désormais dans un venv isolé du job (`/tmp/semgrep-venv`, pin 1.157.0) car ses dépendances contredisent l'env principal (`tomli~=2.0.1` vs pip-audit ≥ 2.10, `pyjwt~=2.12.0` vs PYSEC-2026-178) ; (4) plancher `pyjwt[crypto]>=2.13.0` dans requirements.txt (transitif de mcp) et `pip install -U pip setuptools` dans le job (nouveaux advisories pip PYSEC-2026-3721, setuptools PYSEC-2026-3447). Validation : environnement frais reconstitué en local → résolution sans conflit (pyjwt 2.15.1), pip-audit exit 0, semgrep 1.157.0 exit 0 sur `semgrep-rules/`. Au passage documenté : security échouait déjà avant ce push (v2.31.0/v2.32.0 rouges) et les commits de features n'ont déclenché aucun run (Gitea : commit de tête uniquement) | 🟢 corrigé (en attente vérif utilisateur) |
| 2026-09-28 | #153 A6 → A17 (v2.33.0 → v2.39.0) | Feature + clôture documentaire (aucun bug nouveau) | `CHANGELOG.md`, `docs/features/xlsx-viewer.md`, `docs/GUIDES/RECHERCHE_PDF_EXCALIDRAW.md`, `README.md`, `README.fr.md` | **Clôture du backlog #153** : entrées CHANGELOG des 7 sous-tâches, fiche `features/xlsx-viewer.md` (statut terminé, cases A6-A17 cochées, historique), section 6 du guide utilisateur étendue (barre de formule, navigation clavier, tri/filtre/recherche/export CSV, structure, styles, formats `.xlsm`/`.xls`/`.ods`/`.csv`, tableau de bord) et bullets README FR/EN. Code livré : v2.33.0 A6 (outils IA `backend/tools/spreadsheets.py`), v2.34.0 A7 (clavier + barre de formule), v2.35.0 A13 (tri/filtre/recherche/export), v2.36.0 A14 (structure `PUT …/xlsx/structure`), v2.37.0 A15 (styles/fusions/volets figés), v2.38.0 A16 (`.xlsm` éditable, `.xls`/`.ods` lecture seule, `.csv` RFC 4180), v2.39.0 A17 (dashboard `GET …/xlsx/dashboard`). Vérifié : suite xlsx 116 passed, xlsx-viewer.test.mjs 35/35, ruff/mypy 0, i18n parity, validate-imports 40 modules | ✅ livré (en attente vérif utilisateur) |
| 2026-09-28 | BUG-089 (#153 A5, A10, A12) | Correction | `backend/xlsx_reader.py`, `backend/indexer.py`, `backend/search.py`, `backend/services/mutations.py`, `frontend/js/viewer.js`, `frontend/style.css`, `frontend/locales/{fr,en}.json`, `tests/test_xlsx_viewer.py` | **Les tableurs deviennent visibles ettypés** : (A5) `extract_indexable_text()` indexe noms de feuilles + 20 premières lignes (plafond 5 k caractères) dans le TF-IDF et la recherche sémantique — un mot tapé dans une cellule rend le fichier trouvable ; (A10) `_coerce_xlsx_value()` reconnaît désormais les booléens (`TRUE`/`FAUX`/`OUI`/`NON`) et les dates FR `JJ/MM/AAAA` (jour-first : `01/02/2026` = 1er février), symétrique avec l'affichage ; (A12) la valeur calculée en cache s'affiche sous la formule (`<span class="xlsx-cached">`, 2ᵉ lecture `data_only=True` uniquement si l'archive contient un `<v>`), info-bulle traduite via `xlsx.cached_value_title` FR/EN. (BUG-089) un reindex manuel reconstruisait mal l'index inversé et `backend/search.py` lisait l'index par valeur. Contre-preuves vérifiées pour A5, A10 et A12. Vérifié : `test_xlsx_viewer.py` 43 passed, suite 1402 passed / 6 skipped, ruff 0, mypy 0, i18n parity, validate-imports 40 modules, xlsx-viewer.test.mjs 10/10 | 🟢 corrigé (en attente vérif utilisateur) |
+1 -1
View File
@@ -1,6 +1,6 @@
# ObsiGate — Roadmap
> **Version :** 2.39.5 | **Dernière mise à jour :** 2026-09-29
> **Version :** 2.39.10 | **Dernière mise à jour :** 2026-09-29
> **Ce fichier ne contient que le travail à venir** (🔵 En cours + ⚪ Backlog) et un index compact
> vers les fonctionnalités livrées.
> - **Méthode de livraison à appliquer pour toute tâche : [DELIVERY_WORKFLOW.md](./DELIVERY_WORKFLOW.md)**
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "obsigate",
"version": "2.39.5",
"version": "2.39.10",
"description": "**Porte d'entrée web ultra-léger pour vos vaults Obsidian** — Accédez, naviguez et recherchez dans toutes vos notes Obsidian depuis n'importe quel appareil via une interface web moderne et responsive.",
"main": "patch.js",
"directories": {
+165 -6
View File
@@ -1,4 +1,4 @@
"""Garde-fous du workflow CI Gitea (BUG-082, BUG-083).
"""Garde-fous du workflow CI Gitea (BUG-082, BUG-083, BUG-091, BUG-093).
Sans dépendance (pas de PyYAML) : analyse ligne à ligne de
`.gitea/workflows/ci.yml`, suffisante pour les conventions de ce fichier.
@@ -9,9 +9,29 @@ import re
from pathlib import Path
CI_YML = Path(__file__).resolve().parent.parent / ".gitea" / "workflows" / "ci.yml"
REQUIREMENTS = Path(__file__).resolve().parent.parent / "backend" / "requirements.txt"
REPO_ROOT = Path(__file__).resolve().parent.parent
def _job_text(job: str) -> str:
"""Corps YAML du job `job` (jusqu'au job suivant ou à la fin du fichier)."""
text = CI_YML.read_text(encoding="utf-8")
start = text.index(f"\n {job}:")
rest = text[start + 1 :]
nxt = re.search(r"\n {2}[A-Za-z][A-Za-z0-9_-]*:\s*\n", rest)
return rest[: nxt.start()] if nxt else rest
def _steps(job: str) -> list[tuple[str, str]]:
"""[(nom d'étape, corps YAML)] pour un job donné."""
chunks = re.split(r"\n {6}- name: ", "\n" + _job_text(job))[1:]
steps = []
for chunk in chunks:
name, _, body = chunk.partition("\n")
steps.append((name.strip(), body))
return steps
def _run_bodies() -> list[tuple[int, str]]:
"""Toutes les lignes shell de chaque bloc `run:` → [(n° ligne, code)]."""
lines = CI_YML.read_text(encoding="utf-8").splitlines()
@@ -62,14 +82,99 @@ class TestRunnerProofScripts:
class TestSemgrepStep:
def test_semgrep_local_rules_enforced(self):
"""#87 T7 : semgrep bloquant sur règles locales (aucun registre)."""
text = CI_YML.read_text(encoding="utf-8")
assert "semgrep --config semgrep-rules/ backend/" in text, (
"#87 T7 : étape semgrep locale attendue dans le job security"
"""BUG-091 : semgrep-core est inexécutable sur le runner (exit 127).
L'étape est donc désactivée (avertissement, non bloquante) au lieu d'être
supprimée : elle documente pourquoi, et se réactive telle quelle dès que le
runner dispose d'un CPU x86-64-v2.
"""
SEMGREP_STEP_PREFIX = "Semgrep"
def _semgrep_step(self) -> tuple[str, str]:
matches = [
(n, b) for n, b in _steps("security") if n.startswith(self.SEMGREP_STEP_PREFIX)
]
assert len(matches) == 1, (
"BUG-091 : une unique étape Semgrep (désactivée) attendue dans le "
f"job security, trouvé {len(matches)}"
)
return matches[0]
@staticmethod
def _run_commands(body: str) -> list[str]:
"""Commandes shell du bloc `run:` de l'étape (hors lignes vides)."""
m = re.search(r"^\s*run:\s*\|?\s*$", body, re.M)
assert m, "étape sans bloc `run:`"
rest = body[m.end() :]
lines: list[str] = []
for line in rest.splitlines():
if not line.strip():
continue
# le bloc run: est indenté de 2 spaces de plus que la clef
if len(line) - len(line.lstrip()) <= 8:
break
lines.append(line.strip())
return lines
def test_semgrep_step_does_not_execute_core(self):
"""Le core natif ne doit plus être lancé (exit 127 bloquant le job).
Seule commande admise : l'avertissement d'activation. Le message
mentionne voluntaryirement « semgrep » — c'est l'**exécution** qui
est interdite, pas le mot.
"""
name, body = self._semgrep_step()
commands = self._run_commands(body)
assert commands, f"BUG-091 : l'étape « {name} » n'a plus de commande"
for cmd in commands:
assert cmd.startswith('echo "::warning::'), (
f"BUG-091 : l'étape « {name} » ne doit exécuter qu'un avertissement, "
f"trouvé : {cmd!r}"
)
def test_semgrep_step_is_non_blocking_and_explains_itself(self):
"""Désactivée = `continue-on-error` + avertissement explicite."""
name, body = self._semgrep_step()
assert re.search(r"^\s*continue-on-error:\s*true\s*$", body, re.M), (
f"BUG-091 : l'étape « {name} » doit porter continue-on-error: true"
)
assert "::warning::" in body, (
f"BUG-091 : l'étape « {name} » doit émettre un ::warning:: "
"expliquant la désactivation"
)
assert "BUG-091" in body, (
f"BUG-091 : l'étape « {name} » doit référencer BUG-091"
)
def test_bandit_and_pip_audit_stay_blocking(self):
"""La désactivation de semgrep ne doit rien dégraver d'autre (#87)."""
found = {}
for name, body in _steps("security"):
low = name.lower()
if low.startswith("bandit"):
found["bandit"] = body
elif low.startswith("pip-audit"):
found["pip-audit"] = body
assert set(found) == {"bandit", "pip-audit"}, (
f"étapes Bandit et Pip-audit attendues dans le job security, "
f"trouvé {sorted(found)}"
)
for tool, body in found.items():
assert "continue-on-error: true" not in body, (
f"BUG-091 : l'étape {tool} doit rester bloquante (#87)"
)
def test_semgrep_rules_still_shipped_and_documented(self):
"""Les règles locales restent versionnées et documentées (#87 T7)."""
rules = REPO_ROOT / "semgrep-rules" / "obsigate-python.yaml"
assert rules.exists(), "ruleset semgrep manquant"
text = CI_YML.read_text(encoding="utf-8")
# La commande locale est documentée (commentaire de l'étape), pas exécutée.
assert re.search(r"semgrep --config semgrep-rules/\s*\n?\s*#?\s*backend/", text), (
"#87 T7 : commande locale `semgrep --config semgrep-rules/ backend/` "
"attendue en commentaire dans le workflow"
)
class TestFrontendStepsHaveTheirDeps:
@@ -113,3 +218,57 @@ class TestFrontendStepsHaveTheirDeps:
f"BUG-082 : `{suite}` attendu dans les deux branches de "
"l'étape JSDOM"
)
_SPEC_RE = re.compile(
r"^([A-Za-z0-9._-]+)\s*(?:\[[^\]]*\])?\s*(>=|==|~=|>|<)\s*([0-9][^\s;#]*)"
)
def _floor(pkg: str) -> tuple[int, ...] | None:
"""Plancher `>=` déclaré pour `pkg` dans backend/requirements.txt."""
for raw in REQUIREMENTS.read_text(encoding="utf-8").splitlines():
line = raw.strip()
if not line or line.startswith("#"):
continue
m = _SPEC_RE.match(line)
if not m or m.group(1).lower() != pkg or m.group(2) != ">=":
continue
return tuple(int(p) for p in re.match(r"[0-9]+(?:\.[0-9]+)*", m.group(3)).group(0).split("."))
return None
class TestDependencySecurityFloors:
"""Planchers de sécurité des dépendances (#87, BUG-091, BUG-093).
`pip-audit` est bloquant dans le job `security`. Comme l'image du runner
(`catthehacker/ubuntu:act-latest`) embarque des paquets *préinstallés* dans
sa toolcache Python, un plancher trop bas est « already satisfied » et
n'est jamais mis à niveau : c'est exactement ce qui a fait échouer le
job sur pypdf 6.16.0 (PYSEC-2026-3910 / PYSEC-2026-3911, DoS de ressources
atteignables via backend/pdf_reader.py).
"""
#: (paquet, plancher minimal, advisories corrigées au-dessus)
FLOORS = {
"pypdf": (6, 16, 1), # PYSEC-2026-3910, PYSEC-2026-3911 (fix 6.16.1)
"pyjwt": (2, 13, 0), # PYSEC-2026-178 (fix 2.13.0)
}
def test_security_floors_are_declared(self):
missing = [p for p in self.FLOORS if _floor(p) is None]
assert not missing, (
"plancher `>=` manquant dans backend/requirements.txt pour : "
f"{missing}"
)
def test_security_floors_are_high_enough(self):
too_low = {
p: (_floor(p), minimum)
for p, minimum in self.FLOORS.items()
if (_floor(p) or ()) < minimum
}
assert not too_low, (
"BUG-093 : plancher(s) sous le correctif de sécurité, "
f"le job `security` (pip-audit bloquant) échouerait : {too_low}"
)