fy59/labfy-investigation

Fork 0

Initialiser les outils externes en arrière-plan au démarrage #43

New issue

Closed

opened 2026-07-18 09:19:43 +02:00 by fy59 · 0 comments

fy59 commented

2026-07-18 09:19:43 +02:00

Owner

Initialiser les outils externes en arrière-plan au démarrage

Objectif

Initialiser le catalogue et le registre des outils externes au démarrage de Labfy Investigation sans bloquer l’interface GTK.

L’application doit pouvoir :

enregistrer les outils du ToolCatalog dans le ToolRegistry ;
rechercher les exécutables présents sur le système ;
détecter leur version lorsqu’ils sont disponibles ;
signaler les outils absents ;
afficher la progression dans le panneau des tâches ;
rester utilisable pendant toute l’initialisation.

Contexte

Les composants suivants existent déjà :

ToolRegistry ;
ToolCatalog ;
ToolProcess ;
ToolTask ;
BackgroundTask ;
TaskManager ;
TaskPanel.

L’initialisation ne doit pas refaire leur travail. Elle doit seulement les orchestrer proprement.

Comportement attendu

Au démarrage :

créer ou récupérer le ToolRegistry de l’application ;
enregistrer les entrées par défaut du ToolCatalog ;
lancer une tâche d’initialisation en arrière-plan ;
actualiser la présence des exécutables ;
détecter la version de chaque outil disponible ;
enregistrer les versions détectées dans le registre ;
conserver l’état MISSING pour les outils absents ;
terminer la tâche avec un résumé.

Exemple de résumé :

Initialisation terminée :
- 4 outils disponibles
- 1 outil absent
- 3 versions détectées
- 1 version non détectée

Contraintes

ne jamais bloquer la boucle principale GTK ;
ne jamais appeler directement une fonction GTK depuis le thread de travail ;
ne jamais lancer de shell ;
utiliser les composants existants ;
permettre l’annulation ;
empêcher deux initialisations simultanées ;
ne pas installer automatiquement les outils absents ;
ne pas effectuer de recherche réseau ;
un outil optionnel absent ne doit pas empêcher le démarrage ;
une erreur de détection de version ne doit pas annuler toute l’initialisation ;
l’arrêt de l’application doit annuler proprement la tâche en cours.

Gestion des résultats

Outil disponible et version détectée

state = AVAILABLE
detected_version = valeur détectée

Outil disponible mais version non détectée

state = AVAILABLE
detected_version = NULL

L’erreur doit être enregistrée dans le compte rendu, sans rendre l’outil absent.

Outil absent

state = MISSING
detected_version = NULL

Annulation

La tâche doit passer dans l’état annulé sans modifier les outils qui n’ont pas encore été traités.

Architecture proposée

Créer un composant central :

include/core/tool_initializer.h
src/core/tool_initializer.c
tests/test_tool_initializer.c

API minimale proposée :

typedef struct ToolInitializer ToolInitializer;

ToolInitializer *tool_initializer_new(
    ToolRegistry *tool_registry,
    TaskManager *task_manager,
    GError **error
);

void tool_initializer_free(
    ToolInitializer *tool_initializer
);

gboolean tool_initializer_start(
    ToolInitializer *tool_initializer,
    GError **error
);

gboolean tool_initializer_cancel(
    ToolInitializer *tool_initializer,
    GError **error
);

gboolean tool_initializer_is_running(
    const ToolInitializer *tool_initializer
);

Le nom exact de l’API pourra être ajusté pendant l’implémentation si une structure plus propre apparaît.

Propriété des objets

Le ticket doit définir clairement :

qui possède le ToolRegistry ;
qui possède le TaskManager ;
qui possède le ToolInitializer ;
qui libère la tâche ;
qui conserve le résultat ;
ce qui se passe lors de la fermeture de l’application.

Le ToolInitializer ne doit pas libérer les objets qui lui sont seulement prêtés.

Intégration dans l’application

L’application devra posséder les services centraux nécessaires :

ToolRegistry
TaskManager
ToolInitializer

L’initialisation doit commencer après la création des services principaux, sans attendre son achèvement pour afficher la fenêtre.

Tests obligatoires

Créer des exécutables factices dans un dossier temporaire et contrôler le PATH de test.

Tester au minimum :

arguments invalides ;
création valide ;
démarrage ;
double démarrage refusé ;
registre rempli avec les outils du catalogue ;
outil disponible détecté ;
outil absent détecté ;
version enregistrée ;
erreur de version non fatale ;
plusieurs outils traités ;
annulation ;
annulation avant démarrage ;
nouvel essai après une tâche terminée ;
nouvel essai après annulation ;
destruction pendant une tâche ;
absence de blocage prolongé ;
résumé correct ;
aucune fuite mémoire.

Critères d’acceptation

l’interface apparaît sans attendre la détection des outils ;
l’initialisation est visible dans le TaskPanel ;
le registre contient les outils du catalogue ;
les états AVAILABLE et MISSING sont corrects ;
les versions détectées sont enregistrées ;
les erreurs individuelles n’arrêtent pas toute l’opération ;
l’annulation fonctionne ;
aucune fonction GTK n’est appelée depuis le thread de travail ;
make réussit ;
make test réussit ;
git diff --check ne signale rien ;
Valgrind ne détecte aucune fuite liée au nouveau composant.

Hors périmètre

Ce ticket ne doit pas :

installer des paquets ;
télécharger des binaires ;
modifier les dépôts Ubuntu ou Arch ;
intégrer Sherlock, Maigret ou un autre outil OSINT ;
ajouter un écran de configuration complet ;
lancer une enquête automatiquement.

# Initialiser les outils externes en arrière-plan au démarrage ## Objectif Initialiser le catalogue et le registre des outils externes au démarrage de Labfy Investigation sans bloquer l’interface GTK. L’application doit pouvoir : - enregistrer les outils du `ToolCatalog` dans le `ToolRegistry` ; - rechercher les exécutables présents sur le système ; - détecter leur version lorsqu’ils sont disponibles ; - signaler les outils absents ; - afficher la progression dans le panneau des tâches ; - rester utilisable pendant toute l’initialisation. ## Contexte Les composants suivants existent déjà : - `ToolRegistry` ; - `ToolCatalog` ; - `ToolProcess` ; - `ToolTask` ; - `BackgroundTask` ; - `TaskManager` ; - `TaskPanel`. L’initialisation ne doit pas refaire leur travail. Elle doit seulement les orchestrer proprement. ## Comportement attendu Au démarrage : 1. créer ou récupérer le `ToolRegistry` de l’application ; 2. enregistrer les entrées par défaut du `ToolCatalog` ; 3. lancer une tâche d’initialisation en arrière-plan ; 4. actualiser la présence des exécutables ; 5. détecter la version de chaque outil disponible ; 6. enregistrer les versions détectées dans le registre ; 7. conserver l’état `MISSING` pour les outils absents ; 8. terminer la tâche avec un résumé. Exemple de résumé : ```text Initialisation terminée : - 4 outils disponibles - 1 outil absent - 3 versions détectées - 1 version non détectée ``` ## Contraintes - ne jamais bloquer la boucle principale GTK ; - ne jamais appeler directement une fonction GTK depuis le thread de travail ; - ne jamais lancer de shell ; - utiliser les composants existants ; - permettre l’annulation ; - empêcher deux initialisations simultanées ; - ne pas installer automatiquement les outils absents ; - ne pas effectuer de recherche réseau ; - un outil optionnel absent ne doit pas empêcher le démarrage ; - une erreur de détection de version ne doit pas annuler toute l’initialisation ; - l’arrêt de l’application doit annuler proprement la tâche en cours. ## Gestion des résultats ### Outil disponible et version détectée ```text state = AVAILABLE detected_version = valeur détectée ``` ### Outil disponible mais version non détectée ```text state = AVAILABLE detected_version = NULL ``` L’erreur doit être enregistrée dans le compte rendu, sans rendre l’outil absent. ### Outil absent ```text state = MISSING detected_version = NULL ``` ### Annulation La tâche doit passer dans l’état annulé sans modifier les outils qui n’ont pas encore été traités. ## Architecture proposée Créer un composant central : ```text include/core/tool_initializer.h src/core/tool_initializer.c tests/test_tool_initializer.c ``` API minimale proposée : ```c typedef struct ToolInitializer ToolInitializer; ToolInitializer *tool_initializer_new( ToolRegistry *tool_registry, TaskManager *task_manager, GError **error ); void tool_initializer_free( ToolInitializer *tool_initializer ); gboolean tool_initializer_start( ToolInitializer *tool_initializer, GError **error ); gboolean tool_initializer_cancel( ToolInitializer *tool_initializer, GError **error ); gboolean tool_initializer_is_running( const ToolInitializer *tool_initializer ); ``` Le nom exact de l’API pourra être ajusté pendant l’implémentation si une structure plus propre apparaît. ## Propriété des objets Le ticket doit définir clairement : - qui possède le `ToolRegistry` ; - qui possède le `TaskManager` ; - qui possède le `ToolInitializer` ; - qui libère la tâche ; - qui conserve le résultat ; - ce qui se passe lors de la fermeture de l’application. Le `ToolInitializer` ne doit pas libérer les objets qui lui sont seulement prêtés. ## Intégration dans l’application L’application devra posséder les services centraux nécessaires : ```text ToolRegistry TaskManager ToolInitializer ``` L’initialisation doit commencer après la création des services principaux, sans attendre son achèvement pour afficher la fenêtre. ## Tests obligatoires Créer des exécutables factices dans un dossier temporaire et contrôler le `PATH` de test. Tester au minimum : 1. arguments invalides ; 2. création valide ; 3. démarrage ; 4. double démarrage refusé ; 5. registre rempli avec les outils du catalogue ; 6. outil disponible détecté ; 7. outil absent détecté ; 8. version enregistrée ; 9. erreur de version non fatale ; 10. plusieurs outils traités ; 11. annulation ; 12. annulation avant démarrage ; 13. nouvel essai après une tâche terminée ; 14. nouvel essai après annulation ; 15. destruction pendant une tâche ; 16. absence de blocage prolongé ; 17. résumé correct ; 18. aucune fuite mémoire. ## Critères d’acceptation - l’interface apparaît sans attendre la détection des outils ; - l’initialisation est visible dans le `TaskPanel` ; - le registre contient les outils du catalogue ; - les états `AVAILABLE` et `MISSING` sont corrects ; - les versions détectées sont enregistrées ; - les erreurs individuelles n’arrêtent pas toute l’opération ; - l’annulation fonctionne ; - aucune fonction GTK n’est appelée depuis le thread de travail ; - `make` réussit ; - `make test` réussit ; - `git diff --check` ne signale rien ; - Valgrind ne détecte aucune fuite liée au nouveau composant. ## Hors périmètre Ce ticket ne doit pas : - installer des paquets ; - télécharger des binaires ; - modifier les dépôts Ubuntu ou Arch ; - intégrer Sherlock, Maigret ou un autre outil OSINT ; - ajouter un écran de configuration complet ; - lancer une enquête automatiquement.

fy59 closed this issue

2026-07-18 12:17:00 +02:00

No labels

No milestone

No project

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#43

No description provided.