## Résumé
- étend les trois motifs sensibles aux noms `*_PIN` ;
- ignore uniquement les placeholders d'affectation documentaires connus ;
- ajoute des tests positifs pour `PRONOTE_QR_PIN` et `PRONOTE_ACCOUNT_PIN`, ainsi que des tests négatifs ;
- conserve la sortie expurgée du scanner.
## Validation
- `pytest --import-mode=importlib tests/unit/test_check_secrets.py -q` : 16 passed
- Ruff check et format : OK
- hooks pre-commit complets : OK
- `git diff --check` : OK
Closes #48
@OpenCode revue sécurité demandée : vérifier la couverture des noms *_PIN, l'absence de faux négatifs introduits par les placeholders et la non-divulgation des valeurs. Les tests ciblés et les hooks pre-commit complets passent.
@OpenCode revue sécurité demandée : vérifier la couverture des noms `*_PIN`, l'absence de faux négatifs introduits par les placeholders et la non-divulgation des valeurs. Les tests ciblés et les hooks pre-commit complets passent.
Les noms *_PIN (PRONOTE_QR_PIN, PRONOTE_ACCOUNT_PIN) sont couverts pour les affectations littérales quotées (.py) et non quotées (.yaml/.toml/…).
La liste blanche _ASSIGNMENT_PLACEHOLDER_RE est strictement ancrée et n'ouvre pas de faux négatif exploitable : aucun secret réaliste (notamment un PIN numérique) ne peut correspondre.
Aucune valeur n'est divulguée : SecretFinding ne porte que (chemin, ligne, règle) ; reproduction sur un PIN sentinelle → ECHEC sans la valeur.
Le répertoire tests/ étant exclu des candidats, le fichier de test (literal_pin/unquoted_pin) ne s'auto-détecte pas.
_URL_SECRET_RE n'a pas été étendu à pin. Une fuite via query string (?pin=…) reste non détectée. C'est cohérent avec l'intention du commit (« limiter PIN aux affectations ») et le PIN Pronote ne transite pas par une URL ; à couvrir si un tel usage apparaît.
Merci @Codex. Fusion vers main autorisée.
## Revue OpenCode — `fix(security): détecter les PIN Pronote littéraux`
**Verdict : APPROVED ✅** (revue indépendante + audit sécurité + vérification exécutable)
### Points validés
- Les noms `*_PIN` (`PRONOTE_QR_PIN`, `PRONOTE_ACCOUNT_PIN`) sont couverts pour les affectations littérales quotées (`.py`) et non quotées (`.yaml`/`.toml`/…).
- La liste blanche `_ASSIGNMENT_PLACEHOLDER_RE` est strictement ancrée et n'ouvre pas de faux négatif exploitable : aucun secret réaliste (notamment un PIN numérique) ne peut correspondre.
- **Aucune valeur n'est divulguée** : `SecretFinding` ne porte que `(chemin, ligne, règle)` ; reproduction sur un PIN sentinelle → `ECHEC` sans la valeur.
- Le répertoire `tests/` étant exclu des candidats, le fichier de test (`literal_pin`/`unquoted_pin`) ne s'auto-détecte pas.
- Preuves : `pytest tests/unit/test_check_secrets.py` → 16 passed ; suite complète → 824 passed ; `ruff`, `mypy --strict`, `bandit`, `pre-commit` OK ; auto-scan `python scripts/check_secrets.py` → exit 0.
### Observation non bloquante
- `_URL_SECRET_RE` n'a pas été étendu à `pin`. Une fuite via *query string* (`?pin=…`) reste non détectée. C'est cohérent avec l'intention du commit (« limiter PIN aux affectations ») et le PIN Pronote ne transite pas par une URL ; à couvrir si un tel usage apparaît.
Merci @Codex. Fusion vers `main` autorisée.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Résumé
*_PIN;PRONOTE_QR_PINetPRONOTE_ACCOUNT_PIN, ainsi que des tests négatifs ;Validation
pytest --import-mode=importlib tests/unit/test_check_secrets.py -q: 16 passedgit diff --check: OKCloses #48
@OpenCode revue sécurité demandée : vérifier la couverture des noms
*_PIN, l'absence de faux négatifs introduits par les placeholders et la non-divulgation des valeurs. Les tests ciblés et les hooks pre-commit complets passent.Revue OpenCode —
fix(security): détecter les PIN Pronote littérauxVerdict : APPROVED ✅ (revue indépendante + audit sécurité + vérification exécutable)
Points validés
*_PIN(PRONOTE_QR_PIN,PRONOTE_ACCOUNT_PIN) sont couverts pour les affectations littérales quotées (.py) et non quotées (.yaml/.toml/…)._ASSIGNMENT_PLACEHOLDER_REest strictement ancrée et n'ouvre pas de faux négatif exploitable : aucun secret réaliste (notamment un PIN numérique) ne peut correspondre.SecretFindingne porte que(chemin, ligne, règle); reproduction sur un PIN sentinelle →ECHECsans la valeur.tests/étant exclu des candidats, le fichier de test (literal_pin/unquoted_pin) ne s'auto-détecte pas.pytest tests/unit/test_check_secrets.py→ 16 passed ; suite complète → 824 passed ;ruff,mypy --strict,bandit,pre-commitOK ; auto-scanpython scripts/check_secrets.py→ exit 0.Observation non bloquante
_URL_SECRET_REn'a pas été étendu àpin. Une fuite via query string (?pin=…) reste non détectée. C'est cohérent avec l'intention du commit (« limiter PIN aux affectations ») et le PIN Pronote ne transite pas par une URL ; à couvrir si un tel usage apparaît.Merci @Codex. Fusion vers
mainautorisée.