46bf9676a0
**Motivations:** - Ensure all application directories have systemd services enabled at boot - Complete service installation for api-relay, filigrane-api, and clamav-api - Fix dependencies and import issues preventing clamav-api from starting **Root causes:** - Three services (api-relay, filigrane-api, clamav-api) had service files but were not installed in systemd - api-clamav had incorrect node-clamav version (0.12.1) that doesn't exist - api-clamav dependencies were not installed (node_modules missing) - ES module import syntax incompatible with CommonJS node-clamav package **Correctifs:** - Installed api-relay.service, filigrane-api.service, and clamav-api.service in /etc/systemd/system/ - Enabled all three services for automatic startup at boot - Updated api-clamav/package.json: changed node-clamav version from ^0.12.1 to ^1.0.11 - Installed npm dependencies for api-clamav - Fixed ES module import in api-clamav/src/routes/scan.js to use CommonJS-compatible syntax **Evolutions:** - All 7 application services now have systemd services enabled at boot - Complete service coverage: anchorage-api, faucet-api, signet-dashboard, userwallet, api-relay, filigrane-api, clamav-api - All services verified active and listening on their respective ports **Pages affectées:** - api-clamav/package.json - api-clamav/src/routes/scan.js - api-clamav/node_modules/ (new) - api-clamav/package-lock.json (new) - /etc/systemd/system/api-relay.service (new) - /etc/systemd/system/filigrane-api.service (new) - /etc/systemd/system/clamav-api.service (new)
53 lines
3.6 KiB
Markdown
53 lines
3.6 KiB
Markdown
# Pairing "Connecté" — confirmation croisée et affichage
|
||
|
||
## Objectif
|
||
|
||
Afficher "Connecté" sur chaque device une fois que le flux de confirmation signé de l’autre device a été reçu et traité. La confirmation repose sur un message "membre finaliser" signé par les deux devices, publié sur le relais avec version incrémentée, et stockée en IndexedDB.
|
||
|
||
## Rappel
|
||
|
||
Les messages sont envoyés essentiellement chiffrés. Il faut avoir reçu des messages de clé (Diffie-Hellman) pour déchiffrer la clé de chiffrement et, via le hash, récupérer sur le relais le message qui nous concerne.
|
||
|
||
## Flux attendu
|
||
|
||
### Premier device
|
||
|
||
1. Après "Associer le pair", le 1er device a ajouté le pair distant (8 mots BIP32-style du 2e).
|
||
2. Le 1er device envoie un **message "membre finaliser"** qu’il signe.
|
||
3. Ce message doit aussi être signé par le 2e device.
|
||
4. Le 1er device **attend la signature du 2e device** sur ce contrat.
|
||
5. Une fois reçue, il l’ajoute aux signatures du contrat, vérifie que toutes les signatures attendues sont présentes, puis **publie le contrat sur le relais** (à nouveau), avec une **version incrémentée**.
|
||
6. Il garde la version (et le contrat) dans **IndexedDB**.
|
||
7. Quand tout est OK (flux signé du 2e reçu et traité) → afficher **"Connecté"** sur le 1er device.
|
||
|
||
### Deuxième device
|
||
|
||
1. Après "Associer le pair", le 2e device a ajouté le pair distant (8 mots BIP32-style du 1er).
|
||
2. Le 2e device envoie un **message "membre finaliser"** qu’il signe.
|
||
3. Il **envoie sa signature au 1er device** (via relais : message/clé/signature).
|
||
4. Il complète le contrat avec sa signature, **incrémente la version**, et le garde dans **IndexedDB**.
|
||
5. Quand tout est OK (flux signé du 1er reçu et traité) → afficher **"Connecté"** sur le 2e device.
|
||
|
||
## Impacts
|
||
|
||
- **Contrats** : format "membre finaliser" / "membre finalisé", validateurs, signatures multiples.
|
||
- **Relais** : publication message + signatures + clés (chiffrement, DH).
|
||
- **IndexedDB** : stockage des versions et des contrats signés.
|
||
- **Sync** : récupération des messages chiffrés, clés DH, déchiffrement, mise à jour du graphe et détection des confirmations croisées.
|
||
|
||
## Modalités de déploiement
|
||
|
||
- Déploiement classique du front userwallet.
|
||
- Les relais doivent exposer POST message, POST signatures, POST keys (déjà prévus).
|
||
- Aucune migration IndexedDB imposée pour l’existant tant que le protocole n’est pas implémenté.
|
||
|
||
## Modalités d’analyse
|
||
|
||
- Vérifier les logs (console) pour les pairs et contrats.
|
||
- Tester le parcours "Associer le pair" sur les deux devices puis vérifier l’affichage "Connecté" une fois les signatures croisées reçues et le contrat publié.
|
||
|
||
## Statut
|
||
|
||
- **Documentation** : présente.
|
||
- **Implémentation** : faite (message "membre finaliser", échange de signatures, publication relais, stockage IndexedDB, affichage "Connecté"). Version incrémentée : device 1 re-publie M2 (version "2") après réception de la signature du 2e. Détection au Sync : si device 1 a timeout au poll, un « Synchroniser maintenant » vérifie messages + signatures et enregistre la confirmation. **Chiffrement ECDH** : échange de clés publiques (QR/URL `pubkey`, formulaire « Clé du 2e »), `PairConfig.publicKey`, chiffrement `encryptWithECDH`, POST `MsgCle` (algo `AES-GCM-ECDH`, `df_ecdh_scannable` = clé du signataire), déchiffrement au fetch. Type "membre finalisé" (device 2) : non implémenté, les deux signent le même "membre finaliser". **Export/import** : `pairing_confirm` inclus dans l’export, restauré à l’import ; suppression (« Supprimer ») vide aussi `userwallet_pairing_confirm`.
|