fy59/labfy-investigation
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Vérifier l’intégrité d’une preuve depuis l’interface #53

New issue
Closed
opened 2026-07-20 12:44:00 +02:00 by fy59 · 1 comment
fy59 commented 2026-07-20 12:44:00 +02:00
Owner
Copy link

Vérifier l’intégrité d’une preuve depuis l’interface

Contexte

Lors de l’import d’une preuve, Labfy Investigation calcule et enregistre son empreinte SHA-256 dans SQLite.

L’application affiche déjà les preuves dans la sidebar, leur fiche détaillée dans le Workspace et leur statut d’intégrité. En revanche, il n’est pas encore possible de relancer une vérification depuis l’interface afin de confirmer qu’un fichier n’a pas été modifié, supprimé ou rendu illisible depuis son import.

Cette fonctionnalité doit renforcer la chaîne de conservation des preuves numériques sans modifier les fichiers originaux.

Objectif

Ajouter une action Vérifier l’intégrité dans la fiche détaillée d’une preuve.

Lors de son déclenchement, l’application doit :

  1. retrouver le fichier à partir de la racine de l’enquête et de son relative_path ;
  2. vérifier que le chemin résolu reste bien à l’intérieur de l’enquête ;
  3. recalculer l’empreinte SHA-256 du fichier ;
  4. comparer cette empreinte à celle enregistrée dans SQLite ;
  5. déterminer le nouveau statut d’intégrité ;
  6. enregistrer ce statut dans la base ;
  7. actualiser immédiatement la sidebar et la fiche de la preuve ;
  8. afficher un résultat compréhensible dans la barre d’état.

Statuts attendus

  • EVIDENCE_INTEGRITY_STATUS_UNKNOWN : la preuve n’a jamais été vérifiée ;
  • EVIDENCE_INTEGRITY_STATUS_VALID : l’empreinte recalculée correspond à l’empreinte enregistrée ;
  • EVIDENCE_INTEGRITY_STATUS_MODIFIED : l’empreinte recalculée est différente ;
  • EVIDENCE_INTEGRITY_STATUS_MISSING : le fichier n’existe plus ;
  • EVIDENCE_INTEGRITY_STATUS_ERROR : le fichier existe, mais la lecture ou le calcul a échoué.

Architecture attendue

La logique doit rester séparée de GTK et de SQLite :

Workspace
    ↓ demande de vérification
MainWindow
    ↓ callback
Application
    ↓
BackgroundTask
    ↓
EvidenceIntegrityVerifier
    ↓
EvidenceDao
    ↓
rafraîchissement des modèles et du Workspace

Les widgets GTK ne doivent pas accéder directement à SQLite.

Travail demandé

1. Ajouter la mise à jour du statut dans EvidenceDao

Ajouter une fonction publique :

gboolean evidence_dao_update_integrity_status(
    EvidenceDao *evidence_dao,
    const char *identifier,
    EvidenceIntegrityStatus integrity_status,
    GError **error
);

La fonction doit :

  • valider tous ses arguments ;
  • vérifier que le statut appartient bien à EvidenceIntegrityStatus ;
  • mettre à jour uniquement la colonne du statut d’intégrité ;
  • ne modifier aucune autre métadonnée ;
  • retourner une erreur si aucun enregistrement ne correspond à l’identifiant ;
  • utiliser une requête préparée ;
  • respecter la gestion d’erreurs déjà utilisée par le DAO.

2. Créer le vérificateur métier

Créer :

include/core/evidence_integrity_verifier.h
src/core/evidence_integrity_verifier.c

Le module doit être indépendant de GTK.

Il reçoit au minimum :

  • le chemin racine de l’enquête ;
  • le relative_path de la preuve ;
  • l’empreinte SHA-256 enregistrée.

Il doit retourner un résultat contenant :

  • le statut obtenu ;
  • éventuellement l’empreinte recalculée ;
  • éventuellement une erreur technique.

Le vérificateur ne doit jamais modifier le fichier.

3. Sécuriser la résolution du chemin

Le chemin absolu doit être construit à partir de :

racine de l’enquête + relative_path

Après canonicalisation, le chemin obtenu doit rester contenu dans la racine de l’enquête.

Les chemins absolus, les traversées avec .. et les liens symboliques permettant de sortir de l’enquête doivent être refusés.

Une tentative de sortie de l’enquête doit produire un statut ERROR.

4. Réutiliser le calcul SHA-256 existant

Réutiliser le composant déjà employé lors de l’import des preuves.

Ne pas dupliquer une seconde implémentation du calcul SHA-256.

La comparaison des empreintes doit être stricte.

5. Créer une tâche asynchrone

La lecture et le calcul SHA-256 ne doivent pas bloquer le thread GTK.

Créer une tâche dédiée, par exemple :

include/core/evidence_integrity_task.h
src/core/evidence_integrity_task.c

La tâche doit :

  • fonctionner avec TaskManager et BackgroundTask ;
  • être annulable ;
  • transmettre le résultat sur le contexte principal GLib ;
  • conserver ses propres copies des chaînes nécessaires ;
  • libérer proprement toutes ses ressources ;
  • ne jamais manipuler directement les widgets GTK depuis le worker.

6. Ajouter l’action dans le Workspace

Dans la fiche détaillée d’une preuve, ajouter un bouton compact :

Vérifier l’intégrité

Le bouton doit être accompagné d’une infobulle claire.

Le Workspace doit transmettre uniquement l’identifiant de la preuve à travers un callback public.

Exemple d’API :

typedef void (*WorkspaceVerifyEvidenceCallback)(
    const char *evidence_identifier,
    gpointer user_data
);

Le Workspace ne doit ni ouvrir SQLite ni lancer directement la tâche.

7. Relayer l’action jusqu’à Application

Ajouter le relais nécessaire dans :

Workspace
MainWindow
Application

Application doit :

  1. charger le EvidenceRecord complet avec EvidenceDao ;
  2. récupérer la racine de l’enquête ;
  3. lancer la tâche asynchrone ;
  4. désactiver temporairement le bouton de vérification pour cette preuve ;
  5. traiter le résultat de la tâche ;
  6. enregistrer le nouveau statut dans SQLite ;
  7. rafraîchir les modèles des preuves ;
  8. réafficher la fiche de la preuve sélectionnée ;
  9. afficher un message clair dans la barre d’état.

8. Messages utilisateur

Exemples de messages attendus :

Intégrité vérifiée : fichier intact
Intégrité compromise : empreinte différente
Vérification impossible : fichier absent
Vérification impossible : erreur de lecture
Vérification annulée

Une erreur de rafraîchissement de l’interface ne doit pas être présentée comme un échec de la vérification si le statut a bien été enregistré.

Tests unitaires

Ajouter des tests pour EvidenceDao :

  • mise à jour vers VALID ;
  • mise à jour vers MODIFIED ;
  • identifiant inexistant ;
  • statut invalide ;
  • arguments NULL.

Ajouter des tests pour EvidenceIntegrityVerifier :

  • fichier intact ;
  • fichier modifié ;
  • fichier absent ;
  • fichier illisible ou erreur de lecture ;
  • chemin relatif valide ;
  • chemin absolu refusé ;
  • traversée .. refusée ;
  • lien symbolique sortant de l’enquête refusé ;
  • annulation si elle est prise en charge par le module.

Ajouter les nouvelles cibles au Makefile et à la cible globale test.

Critères de validation

Le ticket est terminé lorsque :

  • une preuve intacte devient VALID ;
  • une preuve modifiée devient MODIFIED ;
  • une preuve supprimée devient MISSING ;
  • une erreur de lecture devient ERROR ;
  • le statut est enregistré dans SQLite ;
  • la sidebar est rafraîchie immédiatement ;
  • la fiche du Workspace est actualisée immédiatement ;
  • le bouton ne bloque jamais l’interface ;
  • la tâche apparaît dans le panneau d’activité ;
  • l’utilisateur peut annuler la tâche ;
  • aucun fichier de preuve n’est modifié ;
  • aucune vue GTK n’accède directement à SQLite ;
  • les chemins sortant de l’enquête sont refusés ;
  • tous les tests sont valides ;
  • la compilation réussit avec :
-std=c17 -Wall -Wextra -Wpedantic -Werror

Hors périmètre

Ce ticket ne couvre pas :

  • la vérification de toutes les preuves en une seule action ;
  • la planification automatique de vérifications périodiques ;
  • la signature cryptographique des rapports ;
  • l’horodatage qualifié ;
  • l’export d’un rapport d’intégrité ;
  • la réparation ou la restauration d’un fichier modifié ou absent.
# Vérifier l’intégrité d’une preuve depuis l’interface ## Contexte Lors de l’import d’une preuve, Labfy Investigation calcule et enregistre son empreinte SHA-256 dans SQLite. L’application affiche déjà les preuves dans la sidebar, leur fiche détaillée dans le Workspace et leur statut d’intégrité. En revanche, il n’est pas encore possible de relancer une vérification depuis l’interface afin de confirmer qu’un fichier n’a pas été modifié, supprimé ou rendu illisible depuis son import. Cette fonctionnalité doit renforcer la chaîne de conservation des preuves numériques sans modifier les fichiers originaux. ## Objectif Ajouter une action **Vérifier l’intégrité** dans la fiche détaillée d’une preuve. Lors de son déclenchement, l’application doit : 1. retrouver le fichier à partir de la racine de l’enquête et de son `relative_path` ; 2. vérifier que le chemin résolu reste bien à l’intérieur de l’enquête ; 3. recalculer l’empreinte SHA-256 du fichier ; 4. comparer cette empreinte à celle enregistrée dans SQLite ; 5. déterminer le nouveau statut d’intégrité ; 6. enregistrer ce statut dans la base ; 7. actualiser immédiatement la sidebar et la fiche de la preuve ; 8. afficher un résultat compréhensible dans la barre d’état. ## Statuts attendus - `EVIDENCE_INTEGRITY_STATUS_UNKNOWN` : la preuve n’a jamais été vérifiée ; - `EVIDENCE_INTEGRITY_STATUS_VALID` : l’empreinte recalculée correspond à l’empreinte enregistrée ; - `EVIDENCE_INTEGRITY_STATUS_MODIFIED` : l’empreinte recalculée est différente ; - `EVIDENCE_INTEGRITY_STATUS_MISSING` : le fichier n’existe plus ; - `EVIDENCE_INTEGRITY_STATUS_ERROR` : le fichier existe, mais la lecture ou le calcul a échoué. ## Architecture attendue La logique doit rester séparée de GTK et de SQLite : ```text Workspace ↓ demande de vérification MainWindow ↓ callback Application ↓ BackgroundTask ↓ EvidenceIntegrityVerifier ↓ EvidenceDao ↓ rafraîchissement des modèles et du Workspace ``` Les widgets GTK ne doivent pas accéder directement à SQLite. ## Travail demandé ### 1. Ajouter la mise à jour du statut dans `EvidenceDao` Ajouter une fonction publique : ```c gboolean evidence_dao_update_integrity_status( EvidenceDao *evidence_dao, const char *identifier, EvidenceIntegrityStatus integrity_status, GError **error ); ``` La fonction doit : - valider tous ses arguments ; - vérifier que le statut appartient bien à `EvidenceIntegrityStatus` ; - mettre à jour uniquement la colonne du statut d’intégrité ; - ne modifier aucune autre métadonnée ; - retourner une erreur si aucun enregistrement ne correspond à l’identifiant ; - utiliser une requête préparée ; - respecter la gestion d’erreurs déjà utilisée par le DAO. ### 2. Créer le vérificateur métier Créer : ```text include/core/evidence_integrity_verifier.h src/core/evidence_integrity_verifier.c ``` Le module doit être indépendant de GTK. Il reçoit au minimum : - le chemin racine de l’enquête ; - le `relative_path` de la preuve ; - l’empreinte SHA-256 enregistrée. Il doit retourner un résultat contenant : - le statut obtenu ; - éventuellement l’empreinte recalculée ; - éventuellement une erreur technique. Le vérificateur ne doit jamais modifier le fichier. ### 3. Sécuriser la résolution du chemin Le chemin absolu doit être construit à partir de : ```text racine de l’enquête + relative_path ``` Après canonicalisation, le chemin obtenu doit rester contenu dans la racine de l’enquête. Les chemins absolus, les traversées avec `..` et les liens symboliques permettant de sortir de l’enquête doivent être refusés. Une tentative de sortie de l’enquête doit produire un statut `ERROR`. ### 4. Réutiliser le calcul SHA-256 existant Réutiliser le composant déjà employé lors de l’import des preuves. Ne pas dupliquer une seconde implémentation du calcul SHA-256. La comparaison des empreintes doit être stricte. ### 5. Créer une tâche asynchrone La lecture et le calcul SHA-256 ne doivent pas bloquer le thread GTK. Créer une tâche dédiée, par exemple : ```text include/core/evidence_integrity_task.h src/core/evidence_integrity_task.c ``` La tâche doit : - fonctionner avec `TaskManager` et `BackgroundTask` ; - être annulable ; - transmettre le résultat sur le contexte principal GLib ; - conserver ses propres copies des chaînes nécessaires ; - libérer proprement toutes ses ressources ; - ne jamais manipuler directement les widgets GTK depuis le worker. ### 6. Ajouter l’action dans le Workspace Dans la fiche détaillée d’une preuve, ajouter un bouton compact : ```text Vérifier l’intégrité ``` Le bouton doit être accompagné d’une infobulle claire. Le Workspace doit transmettre uniquement l’identifiant de la preuve à travers un callback public. Exemple d’API : ```c typedef void (*WorkspaceVerifyEvidenceCallback)( const char *evidence_identifier, gpointer user_data ); ``` Le Workspace ne doit ni ouvrir SQLite ni lancer directement la tâche. ### 7. Relayer l’action jusqu’à `Application` Ajouter le relais nécessaire dans : ```text Workspace MainWindow Application ``` `Application` doit : 1. charger le `EvidenceRecord` complet avec `EvidenceDao` ; 2. récupérer la racine de l’enquête ; 3. lancer la tâche asynchrone ; 4. désactiver temporairement le bouton de vérification pour cette preuve ; 5. traiter le résultat de la tâche ; 6. enregistrer le nouveau statut dans SQLite ; 7. rafraîchir les modèles des preuves ; 8. réafficher la fiche de la preuve sélectionnée ; 9. afficher un message clair dans la barre d’état. ### 8. Messages utilisateur Exemples de messages attendus : ```text Intégrité vérifiée : fichier intact Intégrité compromise : empreinte différente Vérification impossible : fichier absent Vérification impossible : erreur de lecture Vérification annulée ``` Une erreur de rafraîchissement de l’interface ne doit pas être présentée comme un échec de la vérification si le statut a bien été enregistré. ## Tests unitaires Ajouter des tests pour `EvidenceDao` : - mise à jour vers `VALID` ; - mise à jour vers `MODIFIED` ; - identifiant inexistant ; - statut invalide ; - arguments `NULL`. Ajouter des tests pour `EvidenceIntegrityVerifier` : - fichier intact ; - fichier modifié ; - fichier absent ; - fichier illisible ou erreur de lecture ; - chemin relatif valide ; - chemin absolu refusé ; - traversée `..` refusée ; - lien symbolique sortant de l’enquête refusé ; - annulation si elle est prise en charge par le module. Ajouter les nouvelles cibles au `Makefile` et à la cible globale `test`. ## Critères de validation Le ticket est terminé lorsque : - une preuve intacte devient `VALID` ; - une preuve modifiée devient `MODIFIED` ; - une preuve supprimée devient `MISSING` ; - une erreur de lecture devient `ERROR` ; - le statut est enregistré dans SQLite ; - la sidebar est rafraîchie immédiatement ; - la fiche du Workspace est actualisée immédiatement ; - le bouton ne bloque jamais l’interface ; - la tâche apparaît dans le panneau d’activité ; - l’utilisateur peut annuler la tâche ; - aucun fichier de preuve n’est modifié ; - aucune vue GTK n’accède directement à SQLite ; - les chemins sortant de l’enquête sont refusés ; - tous les tests sont valides ; - la compilation réussit avec : ```text -std=c17 -Wall -Wextra -Wpedantic -Werror ``` ## Hors périmètre Ce ticket ne couvre pas : - la vérification de toutes les preuves en une seule action ; - la planification automatique de vérifications périodiques ; - la signature cryptographique des rapports ; - l’horodatage qualifié ; - l’export d’un rapport d’intégrité ; - la réparation ou la restauration d’un fichier modifié ou absent.
fy59 closed this issue 2026-07-20 14:26:26 +02:00
fy59 commented 2026-07-20 14:27:05 +02:00
Author
Owner
Copy link

Implémentation terminée.

Fonctionnalités ajoutées :

  • action « Vérifier l’intégrité » depuis la fiche d’une preuve ;
  • recalcul asynchrone du SHA-256 ;
  • résolution sécurisée du chemin de la preuve ;
  • refus des liens symboliques et des traversées de chemin ;
  • détection des fichiers valides, modifiés, absents ou illisibles ;
  • persistance du statut d’intégrité dans SQLite ;
  • actualisation de la liste et de la fiche après vérification ;
  • gestion de l’annulation et du changement d’enquête ;
  • tests unitaires et asynchrones.

L’empreinte SHA-256 de référence n’est jamais remplacée par l’empreinte recalculée.

Tests automatiques et validations manuelles réussis.

Implémentation terminée. Fonctionnalités ajoutées : - action « Vérifier l’intégrité » depuis la fiche d’une preuve ; - recalcul asynchrone du SHA-256 ; - résolution sécurisée du chemin de la preuve ; - refus des liens symboliques et des traversées de chemin ; - détection des fichiers valides, modifiés, absents ou illisibles ; - persistance du statut d’intégrité dans SQLite ; - actualisation de la liste et de la fiche après vérification ; - gestion de l’annulation et du changement d’enquête ; - tests unitaires et asynchrones. L’empreinte SHA-256 de référence n’est jamais remplacée par l’empreinte recalculée. Tests automatiques et validations manuelles réussis.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#53
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?